CP-6 

SYSTEM 

MANAGER 

HANDBOOK 



SYSTEM MANAGER 
HANDBOOK 



SUBJECT 

Description of Techniques for Efficient Operation of an Installation 



SOFTWARE SUPPORTED 

Operating System COO. 



ORDER NUMBER 
CE60-00 



March 1985 



Honeywell 



Preface 



This handbook provides guidelines, procedures, and strategies for the system manager. 
This handbook is intended to be used in conjunction with the CP-6 System Support 
Reference manual (CE41) which gives encyclopedic detail on the system management 
processors. 

The Los Angeles Development Center (L.A.D.C.) of Honeywell Information Systems Inc. has 
developed Computer Aided Publications (CAP). CAP is an advanced document processing 
system providing automatic table of contents, automatic indexing, format control, 
integrated text and graphics, and other features. This manual is a product of CP-6 CAP. 

Reoders of this document may report errors or suggest changes through a STAR on the CP-6 
STARLOG system. Prompt response is made to any STAR against a CP-6 manual, and changes 
will be incorporated into subsequent releases and/or revisions of the manuals. 

The information in this publication is believed to be accurate in all respects. 
Honeywell Information Systems cannot assume responsibility for any consequences 
resulting from unauthorized use thereof. The information contained herein is subject to 
change. New editions of this publication may be issued to incorporate such changes. 



The information and specifications in this document are subject to change without notice. This 
document contains information about Honeywell products or services that may not be available 
outside the United States. Consult your Honeywell Marketing Representative. 



File No.: 1W13 



©Honeywell Information Systems Inc., 1985 



CE60-00 



Table of Contents 



Module 1-1. Pre-inatol lot ion Planning 1 

Need For Planning 1 

Identifying and Categorizing Users 1 

Interrelationships Between Groups 2 

Security 2 

System Aval I obi I i ty 2 

Administration 2 

Planning Account Designations 2 

Sample Grouping Schemes 3 

Scheme 1 - Using Random-number Accounts 3 

Scheme 2 - Account Grouping 3 

Scheme 3 - Account Grouping 3 

Account Wildcarding 4 

Grouping and Packset Allocation 4 

Grouping and PIG/SUPER 4 

Planning File Management Accounts 5 

Module 2-1. Security 7 

Logon Security 7 

File Secur I ty 8 

Account Level Protection 10 

Access Controls 11 

Access Vehicles 12 

Passwords and Encryption 13 

Wt Idcording 13 

Tope Security 13 

Privilege Security Features 14 

User Pr i vi leges 14 

Temporary Privilege Restriction 16 

Privileged Processors and User Processor Privileges 16 

Security Log Facility , . . , 17 

Protecting the Security Log 17 

Logging Access or Attempted Access to Files 18 

Logging User Privilege Changes 18 

Special Monitor Service Logging 18 

Logging System Access and Exit 18 

Operational Security 18 

Physical Security 19 

Security Planning for Data Center Operations 19 

Controlling Listing Distribution 19 

Controlling Tope Writes 19 

Defining Operator Consoles 20 

Program Security 20 

Module 3-1. Device Configuration 23 

Defining the Hardware Configuration via TIGR 23 

Defining Software Parameters via TIGR 25 

Creating a Bootable PO Tape via DEF 27 

Using $XDEF.MINI and $XDEF_FULL 27 

Sample $XDEF_MINI Job 28 

Module 4-1. Introduction to Project and User Authorization 33 

Authorization Process 34 

Default Records 35 

Authorization Record Contents 35 

Using SUPER 43 

Module 4-2. Project Administration 45 

Creating Projects 47 

Administrator Option 54 

Default Options 54 



CE60-00 Table of Contents iii 



Packset Options 54 

List i ng Projects 55 

Administering Projects $4 

Notes on Using SUPER 67 

Module 4-3. User Authorization 69 

Authorization Elements 69 

Establishing Budget Limits 70 

Establishing System Resource Limits and Defaults 70 

Defining Service Limits and Defaults 70 

Defining Physical Resource Limits 70 

Defining Pseudo Resources 71 

Tailoring the Environment to the User 71 

User Authorization Record 71 

Default Record 77 

Creating User Authorizations 77 

User Logon ID 77 

Initiating User Authorization Mode 78 

Requesting Help 85 

Requesting Online Documentation Before Entering a Command 85 

Requesting Syntax Information After an Error Diagnostic 92 

Listing User Authorization Records 94 

Administering User Authorizations 96 

Module 5-1. Defining and Using a CP-6 Network 97 

Creating Local FEPs on a Network 97 

Adding Remote FEPs to a Network 98 

Defining the Remote Nodes and Node Names 99 

Setting Up Links and Virtual Circuits 99 

Configuring the Network 109 

Setting the Boot Information Ill 

Writing the Boot Diskette 112 

Displaying NETCON Information 113 

Booting the System 116 

Maintenance Through NETCON 116 

Changing Line Configuration Parameters 117 

Changing Boot and Handler Parameters 117 

Module 6-1. Introduction to Response and Throughput Tuning Tools 119 

Responsiveness 120 

Time-sharing Responsiveness 120 

TP Responsiveness 120 

Batch Responsiveness 121 

Throughput 121 

Memory Utilization 121 

Input/Output Bottlenecks 122 

PEP Bottleneck 122 

Module 6-2. Collecting CP-6 Statistics 123 

Creating a Ghost STATS User 124 

Creoting on XEQ Command File 125 

Gathering Stat ist ICS 128 

STATS Data Reduction 128 

GOOSE commands 130 

Module 6-3. Using CP-6 Statistics 131 

STATS CPU display and CPU Tuning 132 

STATS CPU Display 132 

STATS RESPONSE Histogram 136 

CPU Tuning 136 

USERS TIGR Parameter 137 

LIMITU CONTROL Parameter 137 

UM CONTROL Parameter 137 

MAXACCT CONTROL Parameter 138 

NPART CONTROL Parameter 138 

PLOCK CONTROL Parameter 138 

Partition Criteria CONTROL Parameters 138 

QMIN CONTROL Parameter 139 

QUAN and PQUAN CONTROL and SUPER Parometers 141 

IOTA CONTROL Parameter 142 

PRI06 and PPRIO CONTROL Parometers and SUPER Parometers 142 

STATS RESOURCE Display for Resources and Resource Tuning 143 



iv Tobte of Contents CE60--00 



STATS RESCXJRCE Disploy for Monitor Resources 143 

Resource Tuning 144 

DOLIST, ENQ. and QUEUE TIGR Parameters 144 

I/O CACHE Tuning 144 

STATS I/O CACHE Disploys 145 

STATS RESOURCE Display for Memory and Memory Tuning 147 

STATS RESOURCE Display for Memory Utilization 147 

STATS USER SIZE Histogram 152 

Memory Tuning 153 

AUTOSHARE CONTROL Parameter 153 

MAXMM CONTROL Parameter 154 

STATS DEVICE Display and Overload Problems 154 

STATS DEVICE Display 154 

Handling Overload Problems 157 

STATS CHANNEL Display and Channel Loading Problems 156 

STATS Channel Display 158 

Handling Channel Loading Problems 159 

STATS PROCESSOR Display and Processor Tuning 159 

STATS Processor Display 159 

Processor Tuning 162 

STATS FEP SUMMARY Display and PEP Tuning 162 

STATS FEP Summary Display 162 

Tuning FEPs 163 

BLOCK and UNBLOCK NETCON Parameters 163 

BUFSIZE NETCON Parameter 163 

INQSZ TIGR Parameter 164 

OUTZSZ TIGR Parameter 164 

STATS STATISTICS Display 164 

Tables: 

Table 1. Security Features 8 

Table 2. File Permissions 11 

Table 3. SUPER Options 47 

Table 4. ADMINISTRATOR Options and Suboptions 48 

Table 5. User Authorization Options and Suboptions 79 

Table 6. LINK Prof i I e Opt i ons 105 

Table 7. VIRTUAL CIRCUIT Profile Options 107 

Table 8. STATS CPU Display Definitions 133 

Table 9. I/O Cache Granule Types 146 

Table 10. STATS RESOURCE Memory Display Definitions 149 

Table 11. STATS DEVICE and CHANNEL Di sp i ay Def i n i t i ons 156 

Table 12. STATS PROCESSOR Display Definitions 161 

Figures: 

Figure 1. Sample Packset Grouping 5 

Figure 2. Project Structure 45 

Figure 3. Project/User Structure 45 

Figure 4. Multilevel Project Structure 46 

Figure 5. Sample Network Linkage Ill 

Figure 6. Sample STATS User ID Creation 124 

Figure 7. STATS_XEO: Sample STATS XEQ Fi I e 125 

Figure 8. STATS.R EDUCTION: Sample STATS Data Reduction Job 129 

Figure 9. Starting STATS Ghost Immediately 130 

Figure 10. Scheduling Start of STATS Ghost 130 

Figure 11. STATS CPU Display 132 

Figure 12. STATS RESPONSE Histogram 136 

Figure 13. STATS INTERACTION Histogram 140 

Figure 14. STATS RESOURCE Display of Monitor Resources 143 

Figure 15. STATS RESOURCE Display of I/O Cache Activity Table 145 

Figure 16. STATS RESOURCE Display of Memory Utilization 148 

Figure 17. STATS USER SIZE Histogram 153 

Figure 18. STATS DEVICE Display 154 

Figure 19. STATS CHANNEL Display 158 

Figure 20. STATS PROCESSOR Display 160 

Figure 21. STATS FEP SUMMARY Display 163 

Figure 22. STATS STATISTICS Display 165 



CE60-ee Table of Contents v 



About This Manual 



This handbook documents how the system manager and the system manager's staff use CP-G 
system processors to set up and run a CP-6 system. The handbook is built as a modular 
document; each module or group of modules documenting one aspect of managing a CP~6 
system. The current publication Includes modules that document: 

o Pre-i nsta I I at i on planning cons i derat ion8» including information on how to establish 
account conventions (Module 1-1). 

o CP-6 security features (Module 2-1). 

o Using the TIGR processor to define a hardware configuration and set software 
porometers (Module 5-1). 

o Using the SUPER processor to creote and maintain projects and logon accounts 
(Modules 4-1 through 4-3). 

o Using the TIGR, NETCON. SUPER and PIGETTE processors to create and boot a CP-6 
network (Module 5-1). 

o Using the STATS processor to generate statistics that con be used in system tuning, 
and how to tune a CP-6 system (Modules 6-1 through 6-3). 

Modules on additional subjects of concern in system management wilt be added to this 
document . 

The tasks of the system management team are diverse and are generally performed by 
people with differing levels of awareness about the system. This document attempts to 
respond to that diversity. 

Some modules assume a thorough knowledge of the system and are presented as annotated 
examples of how to do a particular system management task. Module 3-1, 'Device 
Configuration' and Module 5-1, 'Defining and Using a CP-6 Network' ore examples of this 
type of module. 

Other modules (for example. Module 4-2 and 4-3 on Project and User Authorization) are 
written In a more tutorlot style for o less seasoned user. 
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Module 1-1 

Pre-installation Planning 



Need For Planning 

If you ore a newcomer to the world of large t ime-shar ing systems, there ore several new 
concepts that might be new to you. If you ore an old hand, you will find that the CP-6 
system has some unique ways of solving old problems. A re-thinking of the way you 
currently solve these problems is in order so that the full range of 09-6 capability Is 
available to you, especially in the areas of security and performance. 

This module will point out some of the decisions that must be made early which will 
affect how you wilt configure your system. Correct choices in the manner of use of CP-6 
features will moke the rest of the system management job much easier. The problems to 
be solved will be discussed in this module; the choices of methods available to solve 
them ore discussed in later modules. The tools (i.e., system management processors) 
used by these methods are fully described in the System Support Reference manual (CE41). 



Identifying and Categorizing Users 

One of the first tasks involved in pre-l nsta I I at i on planning is to identify ond 
categorize the users of the system. The user-grouping scheme that is Implemented by the 
system manager will have profound implications upon the performance of the CP-6 system; 
this module will attempt to explore these implications in detail, present some exomples 
of grouping systems, and illustrate how these are implemented in a CP-6 system. 

A CP-6 user may be an online user at a terminal, a batch job, a CP-6 ghost, or a 
transaction processing user. All users share common characteristics (such os the 
maximum CPU-time and resources useable by the user). These characteristics common 
characteristics; these are defined in the System Support Reference manual (CE41) under 
User Authorization. 

Users may be grouped: 

o By shared interest 

o By existing organizational structure 
o By common accounting requirements 
o By arbitrary schemes 

Some of these methods of categorizing users may overlap. Tor example, users may be 
grouped according to on existing organizational structure, but within several projects 
there may be common support functions which can be identified as such. This can be 
useful in accounting or in statistical analysis. 

For example, Projects A, B, and C may all have a common function such as testing. 
Despite being attached to different projects, the testing function has similar 
requirements. By incorporating a common identifier (e.g., TEST) within the account 
designation for each testing subgroup (e.g.. ATEST, BTEST, CTEST) , the system manager 
can take advantage of the CP-6 feature, witdcording. Substituting the wildcard 
character (?), as in the account specification ?TEST, identifies all accounts ending in 
TEST. Wildcording allows the system manager to refer to a class of accounts rather than 
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identifying each account individually. More important than the convenience factor is 
that the system manager can use wildcarding to restrict file access to specific 
subgroups, or implement account procedures which affect only specific subgroups. (The 
heading ^Planning Account Designations' provides more detailed information on this 
top 



dina 
ic.) 



Interrelationships Between Groups 

In defining the interrelationship between user groups, important considerations are: 

o Security 

o Avai lobi I i ty 

o Administration or control 

Security 

The following security questions should be taken into account: 

1. Which groups should be permitted to access another's files, or be prevented from 
accessing them — for security reasons, or to avoid accidental damage? 

2. Which groups should be restricted to the use of only a specific processor or group 
of processors? 

System Ava 1 L ab i L 1 ty 

1. Which groups must be supported in degraded performance mode, and which groups are 
"expendable" given the necessity to make a choice? 

2. Which groups should have their files stored in duplicate (i.e., DUALed via the EFT 
processor) and thus restored quickly in the event of disk hardware incapacity? 

3. Which groups are autonomous in their file requirements? 

Adm i n i s t r a t i on 

In considering project administration as applied to grouping, the system manager must 

determine the scope of the project i.e., what CP-6 resources will be required, ond what 
constraints are to be imposed. 

Planning Account Designations 

In a CP-6 system, each user runs under a user ID that consists of 
"account , name , password" . 

o account con be two or more things. It defines the user's file management 

account. It also defines the "access key" to be used to gain access to the files of 
others. It is the account field that appears on access lists attached to files, 
accounts, and pocksets. When used in conjunction with CP-6 wildcarding, "account" 
is the cornerstone of CP~6 security and file management procedures. If the 
"account" matches (or fails to match) an account in a file access list, occess is 
granted (or denied). 

o name is only used by accounting routines as a way of separating users with the 
same account. The NAME identifies the individual user; however, there ore grouping 
schemes in which the user NAME incorporates an additional designator which may serve 
to identify department or project. See grouping scheme 3 below. 

o possword is used only by the user. 
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Sample Grouping Schemes 



At this point it might be a good idea to look at several schemes for grouping users, and 
discuss the advantages and disadvantages of each. 



Scheme 1 - Using Random-number Accounts 

When random numbers ore assigned as accounts, there is, in effect, no grouping scheme. 
The user is identified by a name assigned to him ond an account number. Each user 
within a project uses the same account number for accounting purposes, but this is a 
number which has been assigned with no classification or grouping scheme in mind. This 
has advantages for security reasons. However, it becomes laborious and time consuming 
to assign different projects access to common files, as CP-6 wildcording con not be used 
to achieve this. The larger the number of accounts in this type of scheme, the more 
unwieldy the handling of accounts becomes, from a file access-granting standpoint, 
unavoi I able. 



Scheme 2 - Account Grouping 

A commonly used grouping scheme is one that assigns a two-tetter designator for a 
department code, a three-number designator for a project code, a single letter to 
designate the user's job title, and a two-number programmer number. 

By means of illustration, assume on installation has assigned an account as follows: 

CDe02A00 

Where: CD Represents the department code 
002 Represents the project code 
A Represents the user's job title 
00 Represents the programmer number 

(Only project leaders receive a 00 number) 

With this grouping scheme, the advantages of CP-6 wildcording may be demonstrated: 
Through use of wildcording, account access attributes may be set to limit the 
accessibility (READ, WRITE, NOLIST, etc.) of individual files to account groups. 
Assume the following 'MODIFY' command is issued for a specific file: 

IMOD fid TO (ACC«(CD?,READ),ACC«(CD?00,WNEW).ACC=(?,r4OLIST)) 

All accounts with the 'CD' prefix would hove 'READ' access, those accounts with on 'CD' 
prefix and a '00' suffix would hove 'WNEW' access (the ability to write new records), 
and all other accounts would not be able to 'LIST' the file, except the account within 
which the file resides. 

This technique might be particularly useful when utilized within a software factory 
environment, where programmers ore given separate accounts for each project to which 
they're assigned. Similarly, in on academic environment this might apply where students 
ore given on account for each computer-utilizing course in which they're enrolled. This 
technique can be applied at the account level via PIG. 

Scheme 3 - Account Grouping 

Another grouping scheme uses an eight-letter alphabetic designator for account: 
ZZ2ALPHA 

The first three letters identify the Individual user; the next five letters identify the 
user group. Everyone in the "ALPHA" group may be given access to all other ALPHA 
accounts (?ALPHA). Pockset allocation could be by user groups. 
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In this scheme, since the account designator has no informotion concerning project or 
department number, this Is added as a prefix to the name: 



dddname 

where ddd is the project, and NAME identifies the user. 

Instead of project, ddd moy designate on individual box number. For example, at a 
college site, student printouts are routed via o "box number". To accomplish this, the 
box numbers are made port of the logon: 

ZZZALPHA, 100 JONES 

where 100 is the box number. 



Account NA/idcarcing 

Wildcording as applied to accounts gives the system monoger the obility to "wildcard" 
ACCOUNT specifications in access lists. This allows simplified lists, enabling an 
entire group of accounts to be named by one keyword. Thus, ?HOST will match AHOST, 
AAHOST, BBBHOST, etc. 

It is to the advantage of the system manager if he can divide his world into groups so 
that oil the members of a group require the same type of access to the same type of 
files. It is more desirable to have oil members of the administrative programming staff 
have AOMN in their account than it is to hove each with his own name as the account. It 
is possible to hove ?ADMN or ADMN? in an access list. It is not practical to list 75 
accounts like TOM, DICK. HARRY. MARY, SALLY. SUE, etc. 

Wildcording comes in handy in SUPER also. User privileges maintained by SUPER can be 
changed for a group more easily if the group can be addressed by wildcorded account. 



Grouping and Packset Allocation 

Other reosons for grouping involve packset allocations. File management accounts are 
placed on packsets. These sets can be spread across physical devices or kept on one 
device. A packset may be the only packset on the device, or there may be others on the 
same physical device. User groups should be planned with packsets in mind. The CPS 
file backup processor. EFT. Is optimized for backup and restore by entire packset. If 
users are logically grouped, file maintenance con take place with service interruption 
on a group by group basis. rather than the whole user base. A hardware failure on one 
disk drive need not prevent all groups from accessing their own packsets. Instead, if 
multiple removable packsets ore available, a choice con be mode as to which groups can 
continue to access their packsets, and which groups cannot. 



Grouping and RG/SUPER 

Grouping will also make the Project Administration features of SUPER and PIG more 
readily available. Project Administration is a way of delegating the creation of file 
and user accounts to a less privileged user (e.g.. group leader). This user con only 
create accounts within the subset of privileges and of file space passed down to him 
(e.g., by the system administrator). This is usually not easy to do unless the user 
base is already partitioned into logical groups. 
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Planning File Management Accounts 



After a scheme has been established to identify and categorize users, the next step is 
to map out file management accounts into packsets. At this point it will be necessary 
to determine whether to define a packset per project, multiple packsets per project, or 
multiple projects per packset. It is necessary to: 

1. Determine total storage requirements. 

2. Decide on degree of over-allocation, if appropriate. 

3. Identify access restrictions applied to other projects. 

4. Decide on degree of backup required. 

The next step is to allocate the packsets to physical storage, bearing in mind that a 
physical device failure will affect users of all packsets allocated to thot device. 
From the point of view of performance, putting heavy activity packsets on the same 
physical device will lead to disk arm contention. Backup requirements enter into these 
decisions. In allocating DUALs. the system manager should bear In mind that they ore 
most useful on removable devices. 

Modules in this handbook will provide specific information as to how these 
pre-lnstal lot ion decisions ore implemented in the CP-6 system. 

For example, assume that a system includes three disk spindles. The following figure 
shows how file monogement accounts con be grouped as three separate logical packsets: 
DP|SYS. DP|ALPHA, DP|BETA. In this sample, the SYS packset is split across two physical 
pocks; the BETA packset occupies a portion of one pock; the ALPHA packset is also split 
across two physical pocks. For convenience, account designations could contain common 
identifiers; for instance, file management accounts on the ALPHA packset could end in 
ALPHA to permit use of the wildcard feature (i.e.. referring to accounts on the ALPHA 
packset as ?ALPHA) . 



PRCKSETS DP#SYS, DP#RLPHfl, DP#BETR 



SPINDLE 1 SPINDLE E SPINDLE 3 




Figure 1. Sample Packset Grouping 
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Module 2-1 
Security 



This module describes the CP-6 system ond file security features mode ovoilable to CP-6 
customers. Security ensures that only authorized users can access computer-stored 
information. It protects data against accidental or deliberate unauthorized disclosure, 
as well as unintentional or malicious modification ond destruction. The security 
features described in this section include: 

o Logon security, which controls user access to the system. 

o File security, which provides a considerable array of security techniques including 
occount protection, access controls, posswords and dote encryption. 

o Tope security, which features three levels of ANS tape volume protection: full, 
semi-protected, and unprotected. 

o Privileges, which allow the system manager to control special access to powerful or 
disclosive system features. 

o Processor privileges, which allow the system manager to assign sensitive privileges 
to processors rather than individual users. 

o The security logging facility, which allows the system manager to create on audit 
trail of such system activities as file accesses, privilege use, privileged monitor 
service use and logons. 

The CP-6 system has built-in protections against deliberate attempts to violate 
security. In the CP-6 system, no one can read a disk area before writing to it. If 
only part of a granule contains user data, only that port of the data that belongs to 
the user is mode available. These system features prevent browsing through disk 
granules in a search for sensitive data. 

Data security is a joint responsibility. The CP-6 system must — and does — provide 
the toots to secure data from unauthorized access; but, the system manager and user must 
secure the information by using those tools. Physical security is the responsibility of 
each instollation. Each site must ensure thot dial-up phone tines ore protected, 
offices with hardwired lines are locked and that access to data processing rooms is 
restricted. 



Logon Security 

The first kind of security in a CP-6 system is LOGON authorization. A user must give o 
valid name, account ond password to gain access to the system. The LOGON author i zot ion 
is defined by the system manager using the SUPER processor. Although the password is 
optional when defining LOGON accounts, supplying a password for every account will 
increase overot t system security. Users may change their own password at any time via o 
simple terminal command. Requiring the use of passwords and establishing policies to 
change them often is a strongly recommended practice, as very little privilege is needed 
to see other name/account combinations. 

The LOGON authorizations are kept in two files named :USERS and :HLP in the :SYS 
account. These files are protected by the file access controls described later in this 
module. Only the system processors IBEX. LOGON, NETCON. PIGETTE. PRESCAN, SLUG, TPA ond 
TPCP moy occess these files. 
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The passwords supplied to SUPER for LOGON accounts are irreversibly scrombled when they 
ore stored with the logon information. Passwords given at LOGON time are scrambled in 
the same way» so it is the scrambled version of the passwords that are compared for 
equoiity during the LOGON process. If the user forgets the password, a new one must be 
assigned with SUPER* as even SUPER cannot reverse the scrambling process. 

The user must specify the correct password for the account each time the user logs on to 
the system. On full duplex lines, echoing is turned off during the logon process to 
reduce the possibility of accidental disclosure. If the installation maintains a file 
of SUPER commands for the purpose of recreating accounts, this file must be protected 
caref u II y . 

Logon information is retained in each user's .USERS record including the UTS of the last 
good logon, the number of bod logon ottempts which have occurred during the current 
session, and the number of bad logon attempts which occurred between the lost logoff and 
the most recent logon. Since the recording of bad logon counts is contingent upon the 
existence of a :USERS record, only bod logons which fail the password check will cause 
the count to be incremented. The most recent good logon time will always be recorded 
for timesharing logons. Botch logons will only be recorded if they are submitted from a 
device (e.g., a card reader) or if the logon specified on the {JOB cord does not match 
the spewing user's logon. 

When o CP-6 system is first booted and if no : USERS file exists, SUPER automatically 
builds three logon accounts, :SYS,LJS and :FED, SUPPORT and : SYSTAC . LADC . :SYS has all 
privileges and : FED has enough privileges to allow test and diagnostic programs to be 
run. The accounts ore not passworded. It is strongly recommended that these accounts 
be deleted (:SYS) or passworded (rSYSTAC, rFED) as part of standard tope-boot procedure, 
probably as a part of the SUPER user authorization job. 

In addition to logon security established via SUPER, logons con be monitored as a 
security measure. Logons and attempted logons con be logged in the Security Log by 
setting a system parameter via the CONTROL processor (see Security Log Facility, below). 



Fi le Secur ity 

File security ensures thot only authorized users con access computer-stored information. 
It protects data against accidental or deliberate unauthorized disclosure, as welt as 
unintentional or malicious modification and destruction. 

Storoge medium security features differ depending on whether the medium is disk or tope 
files. If the medium is disk files, the pockset owner controls who con create accounts 
on the pockset and establishes default values for account permissions. If the medium is 
tope files, ANS label protection features ore available. The level of tope volume 
protection used is controlled by on installation option. The system manager con specify 
that tope volumes ore to be fully protected, semi-protected or unprotected. The volume 
owner may, at volume creation time, specify protection for labeled tope. 

The following table summarizes CP-6 Input/output and file management security features: 







Table 1 . Secur t ty 


Features 


Medio 


Owner 


I tems Cont rol led 


Defaults Controlled 


Disk 


Pock set 
owner 

(identified 
by name and 
account) 


Determines 
whether automatic 
or expl ici t 
permission is 
necessary to create 
accounts on the 
pock set. 


Account 

pe rmissions 


Tope 


System 
monager 


Determines 

level of ANS label 

protect ion. 
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Table 1. Security Features (cont.) 


Media 


Owner 


I terns Cont rol led 


Defaults Controlled 


Account 


Account 
owner 

( ident i f i ed 
by name and 
account) 


Grants expl icit 
permissions for 
di rectory access 
and file creat ion. 
Determines whether 
f i les in the account 
will be owned by a 1 1 
users of the account 
or whether ownership 
will be cont rol led 
by name and account. 


Fi le 

permissions 


Fi le 


File owne r 
(ident i f led 
by account 
or name and 
account) 


Grants expl icit file 
permissions: i.e., 

determines which 
accounts and/or 
processors can read, 
update, list, append 
and delete f i les, 
delete records, and 
chonge file attributes. 





Note that: 

o The owner of an account and the owner of the file need not be the some users. While 
typically the account owner will also own all files in the account, particular 
application requirements may dictate other usage. For example, a class teacher may 
set up on account whose files are owned by the members of the class. 

o The levels of security have a hierorchical relationship. A failure at one level 

will prevent progression to the next level. A user who wishes to access a file must 
first pass security at the account level, then at the individual file level. The 
user then gains access to the file's data, where the ability to read the data will 
depend on security at the data level. 

o At each level, the user is granted access to more information. Only the user(s) who 
con pass account level security checks can know the names and the types of the files 
in the account. Only the user(s) who con pass security at the file level can obtain 
other catalog information about the file. If there is security at the data level, 
the file data will be meaningful only if the user can supply the required security 
i nf ormat ion. 

An understanding of file security features assumes a clear understanding of the 
difference between logon accounts and file accounts. Whereas the logon account is the 
account that the user supplies to gain entry to the system, a file account is the 
account name under which a file is cataloged. A file account need not have a 
corresponding logon account, and a logon account need not hove a corresponding file 
account . 

File security features five levels of protection arranged in a hierarchical manner. The 
first level of protection is to isolate secure files on a pack set which is mounted for 
the exclusive use of a single user so that other users are unable to access the files. 
The four other file security levels are: 

1. Account level security, where security features are supplied to all files within the 
occount . 
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2. File level security, where individuol Qccess protections ore applied by file. 

3. Special access level security, where the file access Is permitted only via a 
specific program. 

4. Password/data level security, where file passwords and data encryption ore applied. 

These four file security levels ore the subject of the remainder of this section of the 
module. 

Note that: 

o Files are controlled at both the account level, where defaults for all files in the 
account ore established by the system manager, and at the file level, where defaults 
may be overridden or extended by the creator of a file. At both levels, access 
control lists may be established to specify who may know that a file exists, who may 
read it, who may write new records and/or modify existing ones, who may delete 
records, who may delete or rename the file, and who may change file attributes. In 
addition, at the file level, the file's creator may specify the type of access 
(read, write, execute) as well as an access vehicle (a named run-unit) through which 
the file must be accessed. 

o All files may have passwords and all files may be encrypted. Because some CP-6 
processors do not recognize encrypted files, use of the latter capability for 
protecting files should be evaluated on the basis of the processing to be performed 
on those f i les. 

o File access con be monitored through the Security Log by setting system parameters 
via the CONTROL processor (see ''Security Log Facility*' below). 



Account Level Protection 

Access control on file accounts are maintained by the Packset Initializer processor 
(PIG), which can be run by the system manager or a pock set monager designated by the 
system manager. Four classes of security can be specified: 

1. Mode of the account. If the mode is NOT PROTECTED, the creator and any user with a 
logon account motching the file account can access any of the files in the account 
regardless of access controls on the file except password. If the mode is 
PROTECTED, all users except the creator (name and account) are subject to the access 
controls of the f i Ie. 

2. Directory access. A list of logon occounts that may access the directory may be 
specified. If permission to access the directory is not given, the user is unaware 
that the directory and the files contained therein exist, and access is denied 
regardless of individual file access controls. This permission is always given for 
users whose logon occount matches the file account. 

3. File creation. A list of logon accounts that may create new files in this file 
account may be specified. This permission is always given for users whose logon 
account is the some as the file account. 

4. Access defaults. A list of logon accounts and the default access controls each is 
to hove to the files in this account may be specified. (See the Table "File 
Permissions" for a list of the access controls.) Access controls specified on 
individual files override these default access controls unless the account has the 
MERGEACCESS attribute, which causes them to be concatenated with the defaults. 

All account controls are authorized and changed through commands to the Packset 
Initializer Processor. The account owner defines the qualified accounts and the 
permissions granted. Account permissions con be granted either globally (assigned to 
all or denied to all accounts) or they can be granted to specific accounts. 
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The individual user specifies the third level of security — access controls on 
individual files, usually at the time a file is created. These controls reploce or 
enhance the default from the account level, but cannot override access to the directory. 
Note that each permission is separate: therefore, a user who is permitted to delete a 
record from a file may not be able to read it. The table "File Permissions" lists the 
file access controls a user can establish or modify. 





Table 2 


File Permissions 


Pe rmi ssion 


Access Authorized 




Comments 


AU 


Permission to be the 
administrative user of 
comgroup. 


the 


Al lows a user to col 1 
M$OPEN specifying AU-YES. 
(Only one user at a time 
may act as AU of the 
comgroup; the AU may 
change the comgroup via 
the following service colls 
to the monitor: M$CGCTL, 
M$ACTIVATE, and M$DEACTIVATE: 
the user may obtain infor- 
mation via the service call 
M$CGINFO. A user who uses 
this monitor service shares 
the privilege with any user 
with an AURD access to the 
file.) 


AURD 


Permission to invoke 
restricted monitor services 
to a comgroup that examine 
but do not change the 
comgroup. 


Allows 0 user who is not 
the administrative user to 
invoke any monitor service 
that is restricted to the 
administrative user as long 
as no attempt is made to 
change the comgroup. 


DELF 


Delete file, change file 
name, change file password, 
change file access control 
for both vehicle and 
account . 


Note that the REATTR 
permission is used to control 
who can change al 1 other 
f i le attributes. 


DELR 


Delete records. 




Enables the M$DELREC monitor 
service. 


NOLIST 


Suppress inclusion of 
directory information 
cato 1 og i i st ings . 


f i le 
from 


If assigned, any account with 
this attribute is not 
permitted to discover the 
existence of the file. 


READ 


Read, or position and 
a file. 


read, 


Enables the M$PFIL. M$PRECORD, 
M$READ and M$REW monitor 
serv ices . 


REATTR 


Change file attributes 
except file name, file 
password, and access 
controls. 


» 


Note that the DELF permission 
controls who can change a 
file name, file password, 
and/or access controls. 
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Table 2. Fi ie 


Permissions (cont.) 


Permi ssi on 


Access Authorized 




^OfnniOn I 9 


TCTL 


Pemission to issue term 
control monitor services 
a comgroup. 


i not 

iO 


Enables the monitor services 

QOScriDOu in ovciivn %j vi inv 

Monitor Services Reference 
Manual . 


UPDATE 


Replace existing records 




Enables the following monitor 
services: M$tMRITE for keyed, 
indexed and IREL files; M$WRITE 
with REWRITE for consecutive 
files. Note that another 
permission, WNEW, controls 
who con add new records. 


VEH 


File permissions depend 
the accessing vehicle. 


on 


See the subsection "Access 
Vehicles". 


WNEW 


Add new records to the 

file. 




For keyed, indexed and IREL 
organizations, enables random 
insertion of new records; for 
consecutive files enables 
addition of new records at 
the end of the file. Note 
that a different permission, 
UPDATE, controls who can 
alter on existing record. 



When a user who Is not on owner attempts to access an existing file, a check is made to 
see if there is a list of permissions for this file associated with the user's account. 
If a list Is found, the list determines what the user can do with the file. 

If a user has account permission to access on existing file, but there Is no file 
permission list associated with the account, the user defaults to the account default 
file permission. The system manager or account owner can change the account file 
permission defoult through the PIG processor. 



Access Vehicles 

One of the permissions that con be assigned by a file owner, vehicle permission, permits 
alternate file access to a specific set of processors. The file owner determines which 
processors ore to hove access to the file, what file permissions they are to have, and 
which accounts are to have access through the processor(s) . Each processor is given 
only the file permissions authorized In the vehicle access list. If no file permissions 
are included for the processor in the vehicle access list, no permission Is authorized. 
If access is attempted by a processor not In the list, the remaining account list 
pe rm i ss I ons prevo i t . 
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Passwords and Encryption 



Passwords and data encryption are the two final file security features. They are 
controlled by users. 

The owner of a file can assign a password to a file or change an existing password. If 
a password is assigned to a file, permission to open the file is denied any user 
(including the creating user) who cannot supply the correct password. To further 
enhance security, only a scrambled version of the password is stored with the file. 

Anyone who can write records in a disk file can request that data in the file be 
encrypted. Encryption is available for all file organizations except indexed files. 
Encryption may be specified separately for each record of a file. 

Data con be encrypted and decrypted through both the EDIT and PCL processors. Data is 
encrypted by replacing each character with a computed substitute value. The characters 
are generated from on algorithm which uses as its base a starting number supplied by the 
user called a seed. Because the seed con be specified on each read and write, it can be 
different for each record. The seed is not recorded anywhere in the system, which 
secures it from unauthorized detection. However, this added measure of security places 
0 responsibility on the user to remember the seed. 

Note that some CP-6 processors do not recognize encrypted files. Use of encryption for 
protecting files must be evaluated on the basis of the processing to be performed on the 
file. 



Widcardhg 

Account references in access control lists con be abbreviated through wildcarding, i.e., 
inserting one or more wildcard characters (the question mark character) in an account 
name. Each question mark replaces any number of characters and specifies that the 
characters it replaces con be matched with any character; that is, that the characters 
are not to be included in the match check between the access control list for the file 
and the name of the account requesting access. 

The effect of wildcarding is to allow the system manager to specify a range of accounts 
in access control lists. For example, the occount specification 

XXA? 

specifies that all accounts whose first three characters ore XXA ore to be selected. In 
order to moke use of wildcarding (and to keep access control lists short), it is 
recommended that account names be created so that access con be given or denied to 
groups of users by the use of wildcard characters. Remember, however, that to take 
advantage of wildcarding, all accounts must use the same structure. An access control 
account 'GEO?' intended to give access to geology accounts of the form 'GE03712' will 
also give access to the account 'GEORGE*. 

Refer to the section "Files, Devices and Comgroups" in the CP-6 Programmer Reference 
Manual (CE40) for more details on Wildcarding. 



Tape Security 

The CP-6 file management system offers labeled tape protection both at the volume and 
file levels. (Free and managed (device, unlabeled) topes hove no standard labels and 
therefore cannot be protected.) Volume protection is performed for the volume itself to 
determine if the volume con be written at all, and for the volume owner to determine if 
the volume can be read or written by o specific user. 
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Protecting the volume itself ensures that a labeled tope cannot be overwritten until o 
specified expiration date and that a labeled tape cannot be 'changed' into on unlabeled 
tope or into a labeled tape with a different serial number. The strictness of 
enforcement is specified by the system manager through TIGR or CONTROL commands, and 
falls into one of three protection modes: 



Mode 


Descript ion 


Ful ty protected 


Unexpired labeled tape cannot be overwritten: 
expired labeled tape can be overwritten. 


Semi-protected 


Unexpired labeled tope can only be overwritten 
after an OVER keyin; expired labeled tape can 
be overwritten. 


Unprotected 


Both unexpired and expired labeled tape can be 
overwr i t ten. 



User read and write protection ensures that users other than the volume owner (account 
of user creating the volume) have no access, only read access, or any access to a 
particular volume. These access controls are established by the user at volume creation 
t Ime. 

Access to labeled tape files with a CP-6 specific organization Is controlled by the same 
access control features described above for disk files, except that there are no account 
defaults. These access controls ore established by the user at file creation time. 



Privilege Security Features 

Some features of the system ore so powerful that their use must be controlled and 
restricted. Such special access is granted through privileges. Privileges can be 
granted to individual users or programs. In addition, system security is maintained by 
requiring system processors to have processor privileges in order to run. Such 
processors ore called privileged processors. A third level of privilege security is 
created by requiring special user privileges, called user processor privileges, to use a 
privileged processor. This section describes these three aspects of privilege security. 



User Privileges 

Not oil features of the system need or should be granted to all users. Some features 
ore intended to be used only by those users who need to monitor the system or diagnose 
or fix it. These users need special access, which is granted through privileges. The 
system manager assigns special privileges to these users. Once these rights ore 
granted, the user enables them selectively for any task that requires privileged 
capobi I i t ies. 

The SUPER processor is used to grant privileges to users. Modules 4—1, 4-2, and 4-3 
describe how to use SUPER to assign privileges. (Section 7 or the System Support 
Reference Manual contains a complete list of privileges that con be assigned.) 

Users granted the following powerful privileges con bypass most — if not oil — of the 
system's security. These privileges must not be authorized lightly. 
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Pr i V i I ege Descr i pt i on 



CFEP.MFEP Examine and modify the front end processor. 

EXMM Store into any page of memory. 

EXPM Start/stop performance monitor. 

FM>IAG Read or write any disk granule. 

FMSEC Bypass alt file and tope management security checks. 

GPP Get physical memory pages. 

lOQAOQH Call on I/O devices directly. 

JIT Allow modification of the JIT (including privileges). 

MSYS Allows use of certain features of GOOSE and the use 
of M$RUE. 

SYSCON Partition hardware devices. 

TND Use test and diagnostic services. 



The following privileges do not allow the user to modify the system, but allow the user 
access to information that usually should not be disclosed or that affect system 
performance in such a way that authorization of these privileges should be granted 
spar i ngly . 



Pr i vi lege 


Descr ipt ion 


ASAVE 


Automatically saves user's image if terminal 




connection is lost. 


DISPJOB 


Display status of the jobs of other users. 


FMREAD 


Bypass all file and tape manogement security checks for 




READ only access. 


MAXM 


Allocate memory beyond authorized user limit. 




Display performance statistics. 


SPCLMM 


Examine other users memory. 


SYSLOG 


Write in error log. 



Processors may be created via LINK with certain privileges. To insure that these 
privileges can be effected, run units linked with privileges must be run from :SYS. 
When the processor is fetched from :SYS. those privileges ore in effect regardless of 
whether or not the calling user has those privileges. Therefore, it is critical that 
the system manager know the processors that get moved into :SYS, including their access 
controls and privileges. Some processors check the user's authorization and use M$PPRIV 
to set or M$RPRIV to reset the privileges as needed. The users of these processors 
normally do not, themselves, need to set privileges. For example. EFT is LINKed with 
both powerful and disclosive privileges, but it checks the user authorization to 
determine whether the caller can do SAVEs or only MOVEs. Note. also, that to prevent 
malicious misuse of the privileges, the system manager must never grant write access to 
any file in :SYS. 
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Temporary Privilege Restriction 



The system manager can restrict privileges usually available to users through the use of 
CONTROL processor SYSTEM parameters. 

The parameter PRIVMASK determines a set of privileges which may normally be available to 
users but should not be set active for a while. PRIVMASK may be set to ALL, NONE, or a 
list of individual privileges. That is, if PRIVMASK«(FMSEC, EXMM) . then no user will be 
allowed to set either privilege active until the parameter is altered to allow the 
privileges to be set. Note that: 

o Only a user's active privileges ore affected. 

o PRC privileges (those which come with processors run from :SYS) will not be 

affected; that is, PRC privileges that would usually be set active are still allowed 
to be set active regardless of this parameter. 

If users are on the system when this parameter is set, each user will retain currently 
active privileges until he or she again requests that a privilege be set. An X account 
tool, PRIVWARN may be used to globoly reset specified active user privileges if this Is 
des i red. 

The parameter STEPPRIVMASK determines a set of active user privileges to be reset at job 
step termination. Like PRIVMASK, STEPPRIVMASK may be set to ALL, NONE, or a list of 
individual privileges. The use of this parameter does not restrict any user from again 
setting any authorized privileges. It is intended only to keep a specified set of 
privileges from being carried through multiple job steps unless they ore explicitly set 
at each step. 



PrivBeged Processors and User Processor Privleges 

There ore cases where privileges are so powerful or disclosive of information that it Is 
preferable to grant the privileges to a program rather than to Individuals. 

The system manager con use SUPER to authorize users to utilize specified privileged 
processors without giving the required privileges to the user. Section 7 of the CP-6 
System Support Reference Manual gives more details on processor privileges 
(PPRIVI LEGES) . This technique allows the system manager to change control parameters 
and protect highly dangerous privileges from direct user availability. The privileges 
that can be granted in this way are: 



Pr i V i 1 ege 


Descr i pt i on 


CNTRLC 


Display and change system parameters (CONTROL). 


CNTRLD 


Display system parameters (CONTROL). 


EFT 


Run EFT. 


EL 


Run the Error Log Analyzer (ELAN). 


LABEL 


Write labels on tapes. 


NETCON 


Control the FEP. 


PIGC 


Change pack set status. 


PIGD 


Display pack set status. 


PIGETTE 


Create bootstrap diskettes for remote FEPs. 


RATES 


Run RATES. 


REPLAY 


Run REPLAY. 


SPIOERC 


Change shared processor status. 


SPIDERD 


Display shared processor status. 


SUPER 


Run SUPER. 


SUPERAUTH 


Authorize users. 


SUPERD 


List SUPER doto. 


SUPERFORM 


Create and change forms. 


SUPERWSN 


Authorize and modify workstot ions. 



16 



Privileged Processors ond User Processor Privileges 
Module 2-1 



CE6e-0e 



(cont . ) 


Pr 1 VI lege 


Descr 1 pt i on 


SYSCON 


Control/display availability of hardware 




components 


VOLINIT 


Use VOLINIT. 



Secur ity Log Faci I ity 

The Security Log is a collection of files used to audit the use of certain sensitive 
system facilities. The name of the Security Log is :SECLOGyymmdd, where 'yymmdd' is the 
ANS format for dote. These daily files are maintained in the :SYS account. They are 
Indexed files keyed by primary key only. The fields included in the key are referenced 
in the EL$HDR macro described later in this section. 

The following five types of records can be included in the Security Log files: 

o System access (i.e., logon) records 

o System exit (both logoff and recovery) records 

o Monitor service records 

o Privilege request records 

o File access records 

The system manager determines the types of records included and protects the Security 
Log through CONTROL processor SYSTEM parameters. 

The system manager uses the following CONTROL processor SYSTEM parameters to tune the 
Security Log: 

PROTECTSECLOG 

LOGFILEGRANT and LOGFILEDENY 
PRIVCHNGMASK and L06PRIVCHNG 
MONSERTBL and LOGMONSER 
LOGSYSACCESS and LOGSYSEXIT 

Use of these parometers to tune the Security Log is summarized here. Section 2, 
"CONTROL:HOST System Management" of the CP-6 System Support Reference Manual details the 
parameters. 



Protecting the Security Log 

The CONTROL processor SYSTEM parameter PROTECTSECLOG may be used to specify the number 
of days a security log file will be specially protected by file management since its 
creation. During this time frame, only the security logging processor will be allowed 
to perform any operation other than to read the file. Thereafter the files are 
maintained using standard file management capabilities. Since these files reside in 
:SYS, it is expected that :SYS will have odequate default file access controls to 
restrict perusal by users who do not have special privileges. 
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Logging Access or Attempted Access to Fies 



The CONTROL processor SYSTEM parameter LOGFILEGRANT determines whether certain granted 
file occesses will be logged for any file on the system. Since the decision to log 
granted file access is only available at the system level, these accesses will be logged 
only if a user has sufficient active privileges to cause normal security checking to be 
bypassed. LOGFILEGRANT may be set to YES or NO. 

The parameter LOGFILEDENY determines whether denied accesses to any file on the system 
will be logged. LOGFILEDENY may be set to either YES or NO. 



Logging User Priviege Changes 

It is possible to cause privilege setting activities to be logged in the Security Log. 
The CONTROL processor SYSTEM parameter PRIVCHNGMASK is used to specify a set of 
privileges the use of which is to be logged. LOGPRIVCHNG controls how this set of 
privileges is to be interpreted for logging purposes. If set to NONE, PRIVCHNGMASK will 
be ignored and no logging will be done. Otherwise, it may be set to log only granted 
requests, only denied requests, or both. 



Special Monitor Service Logging 

Certain monitor services permit the usual security mechanisms to be bypassed. 
Therefore, the system manager moy wish to hove the use and/or attempted use of any of 
these monitor services logged in the Security Log. The CONTROL processor SYSTEM 
parameter MONSERTBL may be used to specify a set of special monitor services considered 
interesting enough to be logged. A list of the monitor services that may be specified 
can be found In Section 2 of this manual. LOGMONSER controls how these monitor services 
are to be interpreted for logging purposes. If set to NONE, MONSERTBL will be ignored 
and no logging will be done. Otherwise, LOGMONSER may be set to log only granted usage, 
only denied attempts, or both. 



Logging System Access and Exit 

The CONTROL processor SYSTEM parameter LOGSYSACCESS allows the system manager to 
determine which logons, if any, are to be logged. LOGSYSACCESS moy be set to cause the 
following categories of logons to be logged: (1) none; (2) only logons which foil the 
password check; (3) logons which either fail the password check or look reasonable but 
do not actually exist; (4) logons which fail for any reason at all, including bad 
format; or (5) all logon attempts. 

The parameter LOGSYSEXIT allows the system manager to specify whether system exits, 
either logoffs or exits due to recovery, ore to be logged. It may be set to ALL or 
NONE. 



Operational Security 

A full consideration of operational security must include a discussion of the physical 
plant, the way in which computer center operator's are trained and other subjects that 
ore beyond the scope of a Honeywell publication. Some aspects of operational security 
relate directly to appropriate use of the CP-G system. 

For purposes of this discussion, operational security is divided into the following 
categories: 

o Physical security 

o Security planning for doto center operations 
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Physical Security 



Many books hove been written on the subject of physical security in the data processing 
environment. In those documents, the reader will be confronted with the need to address 
such physical security considerations as locking doors, shredding sensitive listings 
before disposing of them, disposition of carbons, and establishing secured areas. 

Some tape security features ore linked closely with physical security. In the earlier 
port of this section on "Tape Security", the reader was introduced to the three kinds of 
tape protection modes available via CP-6 file management. From a physical security 
aspect, the system manager will need to weigh advantages and disadvantages of two of 
those modes: namely, the fully protected and semi-protected modes, and will normally 
decide in favor of semi-protected mode. Using the fully protected mode provides full 
ANS protection on tapes which guarantees that a tape connot be overwritten. But, fully 
protected topes require operator intervention to mount, and such tapes cannot be 
extended. Their use may prove inconvenient and inefficient. 

The system manager will also wont to give deliberate consideration to establishing 
labeling techniques to guarantee that cross mounting of tapes and private pocks cannot 
occur, thereby assuring that only appropriate users can mount topes and private pocks. 



Security Planning for Data Center Operations 

The system manager will wont to establish policies thot ore explained to the computer 
center operators as port of their training to ensure that: 

o Listing distribution is controlled 

o Writing to topes is controlled 

In addition, operations planning should include some deliberate decisions about how 
operator consoles ore to be defined. 



Controlling Listing Distribution 

Prior to operator training, a system needs to be established for controlling which 
listings can leave the data center and where they con go. It is recommended that in 
planning this security, the system manager consider use of the SUPER processor 
BANNERTEXT feature (described in the section "Device-Form Definition" in the CP-6 System 
Support Reference Manual (CE41)). Through this SUPER option, destinotion fields can be 
defined for inclusion on printout banners to define clearly w ho is to r^eceive outpu t. 
The system manager controls whether those fields can be changeT~or notT ETeli berate 
planning of account naming conventions will help in the planning of this type of 
secur i ty . 



Controlling Tape Writes 

The system manager will want to develop and enforce policies on the use and removal of 
write rings to protect tope data from accidental overwriting. As port of physical 
security planning, the system manager con establish policies to ensure that write rings 
ore removed from tope reels. It is especially important that PO (boot) topes be 
protected from accidental destruction of data. One suggestion is to limit the number of 
write rings available. A short supply of write rings will help guarantee their removal 
from tope reels. 
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Defining Operator Consoles 



At least one lOM-connected system console will probably need to be defined in any 
significant data center so that dramatic system intervention (i.e.. ZAPs and DIEs) can 
be performed. As part of physical security planning, the system manager will wont to 
make sure that system consoles ore not mode generally available, and will want to make o 
deliberate decision about whether and how to establish associated workstations. 

System consoles and their associated workstations should only be established where a 
need is clearly defined for global control. In general, the system manager will wont to 
evaluate the octual specific requirements the operator will hove at the given location. 
In particular, the system manager will want to be deliberote in use of the DEVICE and 
UNPRIV ADMIN console attributes to control who can lock and unlock devices and who has 
administrative privileges. 

Deliberate planning of workstotion names and device names will simplify administrative 
control of the workstations. All workstations controlled by a console can be wiidcarded 
with a single trailing ? (see "Wi I dcord i ng" above). The following considerations may be 
useful in planning operator console security: 

o It is advisable to keep the console history log active to mointoin a record of alt 
privileged transactions and all significant keyins from a console. Since a system 
console con turn the console history tog off, one security measure the system 
manager can take is to ensure that the GOOSE_EGG file contains the necessary 
commands to ensure that the console history log is turned on periodically so that no 
more than one hour's transactions will ever be lost. (See the section "GOOSE: 
Automatic Operations Control" in the CP-6 Systems Support Reference Manual (CE41)). 

o The console history log is maintained in the :SYSTAC account. As part of security 
planning, the system manager may wish to back up the console history tog to a more 
secure account to prevent tampering. 

o An operator's console is intended as an operational tool. Such administrative 

functions as changing system configuration, changing rate tables, authorizing new 
users and creating new accounts require privileges not associated with the console, 
but. rather with the user. If it Is desirable to perform privileged user functions 
from on operator's console then a timesharing logon account must be defined for the 
user of the console. Such users must be counselled as to discreet and suitable use 
of the logon account, and advised to change the password for the account 
pe r I od i CO t I y . 



Program Security 

The segmented structure of Honeywell DPS hardware guarantees the protection of users in 
the CP-6 system so that normally: 

o 0 user cannot see another user 

o Q user cannot see monitor procedure or data. 

This protection is enforced in both the DPS hordware and the CP-6 system architecture. 

In the CP-6 system architecture programs are protected by framing data and using traps. 
Techniques have been established such that attempts to transfer data between domains 
requires that users must frame data within vectors and a hardware instruction, a 
Privileged Master Mode Entry (PMME) CLIMB, is performed so that the monitor is entered. 
All input/output statements ore performed by the monitor in response to PMME 
instructions. Attempts to access data in any other way will cause the hardware to fault 
and CP-6 foult handling processing will take control. This procedure ensures that no 
user will couse damoge to the system or to another user. 
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The CP-6 system includes ways for one user to access another user's dota through special 
privileges which can be assigned to users via the SUPER processor. The SPCLMM privilege 
allows a user to perform a PMME to gain occess to normally invisible areas of procedure 
and data, including the monitor. The EXMM privilege allows a user to write areas of 
memory otherwise not available to a user. The lOQ and lOQfH privileges allow o user to 
circumvent the requirement to perform input/output statements via PMMEs. 
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Module 3-1 

Device Configuration 



After initial booting of a CP-6 system, using the defaults supplied on the PO tope, a 
minimol hordware configuration is operational. To moke the complete hardware 
configuration operational, it is necessary to revise the TIGR deck on the PO tope to 
reflect the complete hardware configuration; the system can then be rebooted to make the 
complete hardware system available for use. For changes or additions to the hardware 
configuration, the some procedure is followed to make new or changed devices known to 
the CP~6 system. 

This module describes how to define a basic hardware configuration and set critical 
software parameters using TIGR commands. It also describes how to create a bootable 
system tape with which to reboot the system. Sample jobs available with the system 
foci I i tote creating a bootable system tape, as Hlustroted. 



Defining the Hardware Configuration via TIGR 

The following example explains how to modify the TIGR commands supplied on the PO tope. 
The TIGR commands on the PO tope define a minimal hardware configuration via the 
AUTOCONFIG command. The system manager should substitute specific definitions of the 
actual configuration by modifying the file T I GR.R EL. SUPPORT which is then used to creote 
0 new PO tope as discussed later. 

The following example modifies the T I GR.R EL. SUPPORT file to reflect a standard local 
configuration: two CPUs, one 10 Multiplexer (lOM), a system console, a disk 
micro-programmed controller (MPC) and several disk drives (one drive is to be installed 
later), a tope micro-programmed controller, and a unit record controller with o line 
printer and cord reader. Four FEPs are defined in the TIGR.REL file; only one FEP 
exists in the sample system. 



!EOIT TIGR_REL. SUPPORT 
EDIT Cee HERE 
♦TY 1-2 

i.eee itigr "L66 cee release tigr deck 

2.000 "TIGR REL" 

The Honeywell release TIGR deck comes on the "tools" tape as the 
file TIGR_REL. SUPPORT. The system manager has requested EDIT to 
dtsploy the first two lines of this file. 

• INI 

1.000 1TI6R "MY am TIGR DECK 
•DE 2 

• 1 records deleted 

The system manager has renamed the TIGR deck from "L66 C00 
RELEASE" to "MY OIMN". the name of the new deck to be built, and 
has also deleted line 2. "TIGR REL". 
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• ty 3 

3.000 AUTOCONFIG 



AUTCXONFIG. line 3.000. the only command in the TIGR deck to 
represent the default local device conf i gurot ion. (In addition 
four FEPs, on channels 33-36, are represented in the TIGR_REL 
file.) 



• IN 3 

3.000 CPU P0RT#-2 
♦IP, .01 

3.010 CPU P0RT#-3 

3.020 lOM PORliM 

3.030 CONSOLE NAIIE-SC01 . 10M#>1 ,CHAN-30 



•IN 3.040, .01 
3.040 DISK 
3.050 
3.060 
3.070 
3.080 
3.090 
3.100 
3.110 
3.120 
3.130 



The system manager informs TIGR that two CPU's ore connected to 
ports 2 ond 3 of the eight-port system control unit, one lOM is 
connected to port 0. One console which must be named SC01 is 
hooked to lOM #1 on channel 30. It is recommended that the 
console always be configured to channel 30. 



MPC,MPCNAME-DC01 ,MODEL>MSP0600 
LA ; 

IOM#«0,CHAN-8-11 



OEV 



NAME»DP01 .MODEL-(MSU0451 .MSF0007) .DEVf-1 .SYSTEM 
NAME-DP02.MODEL-(MSU0451 .MSF0007) ^DEV] 1-2. 
NAME«^P03.MODEL«(MSU0451 .MSF0007) .DEVj U3, 
NAME«bP23,MOD£L«(MSU0501 ,MSF0007) ,DEVi l«23 
NAME-OP25,MODEL-(MSU0501 ,MSF0007) ,DEV|»25,STATUS^X)WN 

These lines, starting with 3.040. are the disk command. Each disk 
must be hooked to the system through an MPC (micro-programmed 
peripheral controller) which in turn hooks to the lOM. The MPC 
must be assigned the disk controller name DC01 . MSP0600, the disk 
model nome. indicates the firmware (for "disk controller'*) 
necessary to load into the MPC. 

Firmware is written, supported, and supplied by Honeywell Field 
Engineering. (Firmware supports the proper interaction between 
the MPC and the host software.) The link adaptor (line 3.060), 
used to hook an MPC to on lOM, is connected to lOM number 0, 
channels 8 through 11 (line 3.070). This portion of the command 
indicates where TIGR is to download the firmware. The devices are 
specified next: the system disk (3.090^, two high-speed 
non— system disks (lines 3.100 and 3.110), o large disk drive, 
wired at a high address since smaller disk drives will be put in 
at lower addresses (line 3.120). To configure the TIGR deck so it 
appears as if the disk is connected but only partitioned out of 
use, STATUS-OO^ (line 3.130) is entered, this to assure easy 
connection of a S01-type disk at a later time. 



•IN 3. 140, .010 
3.140 TAPE ; 

3.150 MPC.MPCNAM£«TC01,MODEL-MTP0610 ; 

3.160 LA : 

3.170 IOM#-0,CHAN-16-17 ; 

3.180 OEV ; 

3. 190 NAMEH^01 ,MODEL-(MTU0630,MTF0636) ,DEV{-1 ; 

3 . 200 NAMEHylT02 .MODEL-( MTU061 0 .MTF0608 ) , DEV|-2 ; 

3.210 NAME-MT03.MODEL«(MTU0610,MTF0608) .DEVjk3 

Topes are connected through on MPC, as are disks after the tape 
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command (line 3.140) has been issued. The MPC name must be TCOI 
to indicate the tape controller number. Next, the tape MPC is 
hooked into a link adaptor in lOM number 6 (the only available 
lOM) with channels 16 and 17 (line 3.170). Line 3.180 through 
3.210 indicate three tape drives and their respective device 
numbers and model numbers connected on the HPC. 

•IN 3.220. .010 
3.220 UNIT ; 

3.230 MPC,MPCNAME"UC01 .MODEL-URP0600 ; 

3 . 240 NAME=LP01 , M0DEL«(PRU1 200 . PRB0600) . IOM#«0 . CHAN-24 . OUT . SYMBIONT ; 

3.250 NAME>-CR01 .MODEL-(CRU0501 ) , IOMf"0.CHAN-26» IN, SYMBIONT 

The MPC name for unit record devices is UC01 , and the ordered 
model is URP0600 (line 3.230). Because each device goes through 
its own channel, a link adaptor is not needed with unit record 
commands. One printer is specified (line 3.240) with name, model 
number, connected through channel number 24 and specified as an 
output symbiont device. Next (line 3.250) a card reader is 
specified on chonnel 26, the default channel. The card reader is 
further designated as an input device (IN) as well as a symbiont 
device (SYMBIONT). 



Defining Software Parameters via TIGR 

The TIGR_REL. SUPPORT file also includes the TIGR command MON which specifies a number of 
software parameters. The system manager should examine these parameters to determine if 
they match the site's requirements. 

The following example gives explanations and recommendations for a number of the 
software options available in the MON command. Of particular interest is the 
information given on the USERS option. Several changes to defaults have been made in 
this example; the MTDFLT option specifying the default tape density has been added to 
the option list; an SPROC option for library :SHARED_RPG has been added. 



1 .000 
3.000 
3.010 
3.020 
3.030 
3.040 
3.050 
3.060 
3.070 
3.080 
3.090 
3.100 
3.110 
3.120 
3.130 
3.140 
3.150 
3.160 
3.170 
3.180 
3.190 



I TIGR "MY OWN TIGR DECK 
CPU P0RT#«2 
CPU PORT3U3 
lOM PORTf-0 

CONSOLE NAME-SC01 , IOmf-1 .CHAN-30 
DISK ; 

MPC , MPCNAME-DC01 , MODEL-MSP0600 
LA : 

IOM#-0.CHAN-8-11 



DEV 



TAPE 



NAME«DP01 .MODEL-(MSU0451 ,MSF0007) .DEV|-1 .SYSTEM ; 
NAME«OP02,MODEL-(MSU0451 ,MSF0007) .OEVj ^2, ; 
NAME-DP03 ,MOOEL=(MSU0451 ,MSF0007) .DEVj ^3. ; 
NAME-{)P23 ,MODEL»(MSU0501 ,MSF0007) , DEVj ^23 ; 
NAME-DP25,MODEL-(MSU0501 ,MSF0007) , DEV#-25 , STATUS-DOIfVN 

MPC , MPCNAME-TC0 1 . MODEL-4ITP06 1 0 ; 
LA ; 

IOM#»0.CHAN«16-17 ; 

DEV ; 

NAME-MT01 ,MODEL-(MTU0630,MTF0636) ,DEV#-1 ; 
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3 . 200 NAMEM^T02 . MODEL»(MTU061 0 , MTF0608) . DEV#»2 : 

3.210 NAME-WT03 . MODE L« ( MTU06 1 0 . MT F0608 ) . DEV#-3 

3.220 UNIT ; 

3.230 MPC.MPCNAME=UC01 .MODEL-URP0600 ; 

3.240 NAME=LP01 .MOOEL-(PRU1200.PRB0600) , IOM|-0.CHAN-24,OUT.SYMBIONT ; 

3 . 250 NAME-CR01 .MODEL=(CRU0501 ) . IOM#«0 .CHAN-26 . IN . SYMBIONT 



4.000 FEP NAME-FEP1.IOI#-0.CHAN33 
8.000 MON ; 



The MON cofwnand (CONTROL processor) sets certain operoting 
parameters of the CP~6 system. The options that follow illustrate 
the setting of some of these parameters: 

9.000 SITE-*JJ"S CP-6',; 

SITE sets the site identification. 

10.000 SAL-**** JJ*'S CP-6 AT YOUR SERVICE',; 

SAL sets the salutation or greeting that will welcome on line 
users when they log on the system. MON can also put BEL 
characters in the quote string if you wish. 

11 .000 IOCACHE-500, ; 

lOCACHE sets the number of memory pages reserved for lOCACHE to 
500. 

♦IP30.1 

10.100 MTOFLT-(1600),; 

MTDFLT specifies the default tape density for device MT. 

10.110 

12.000 STEALPGS«(15,30). ; 

STEALPGS specifies the limit on poges ovoi loble for stealing from 
the monitor, that is, removed from the monitor's list of avai labia 
free pages and used by other system functions. 

13.000 QUEUE«(90,90). ; 

QUEUE sets lOS — the number of IDS packets to be built (the 
maximum number of current and pending local I/O operations), and 
ICQ — the maximum number of current and pending local and remote 
I/O operations. In this case, both lOS ond lOQ are 90. 

14.000 USERS-75,; 

15.000 DOLIST-50,: 

16.000 DEVMAX-100,; 

18.000 ENO-(4,10),: 

The maximum number of users has been set to 75 (line 14). 
However, as fifteen of these slots are always reserved for system 
ghosts, the maximum number of online users is 60. DOLIST—50 
establishes the number of delist blocks to be built; these will be 
used in processing no-wait I/O ond other asynchronous operations. 
DEVMAX establishes the maximum number of devices thot con be 
connected to the system at any one time (including local devices, 
FEP-connected devices, and terminals); in this case, 100. ENQ 
sets the range of numbers of pages assigned for ENQ/DEQ table 
blocks. In this case, the minimiMi has been set to 4; the maximum 
to ten. 
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19.000 CrU«(1 .20). ; 
21 .000 SPSPACE-20. ; 
22 . 000 SPAUTOSPACE«50 , ; 



CFU sets the ronge of numbers of pages assigned for the current 
file usage (CPU) table blocks used by file management. SPSPACE 
designates the number (20) of shared processor slots to be 
reserved for dynamic addition of shared processors. SPSPACE is 
also used by the SPRCXJS option, below. SPAUTOSPACE designates the 
number (50) of automatically shared processor slots to be reserved 
for outoshartng of processors. 

23 . 000 SPROC= ( LOGON . CP ) . ; 

24.000 SPROC=(IBEX.CP). ; 

25.000 SPROC=(dELTA,DB). ; 

26.000 SPROC=(IDS.AS). ; 

27 . 000 SPROC=( : SHARED_COBOL .LI).; 

28 . 000 SPROC=( : SHARED_SYSTEM , L I) . ; 

29 . 000 SPROC«( : SHARED_COMMON . LI ) . ; 

SPROC (lines 23.000 - 29.000) is used to set the status of shared 
processors; SPROC=( IBEX ,CP) indicates Command Processor (CP) 
status (in this case, for the IBEX processor). AS indicates 
Alternate Shared Library status (for IDS); DB indicates debugger 
status (for DELTA); LI indicates Library status. 

♦ EOF hit after 49.000 

♦ IP50 

50 . 000 SPROC« ( : SHARED.RPG .LI) 

The system manager has inserted on LI (Library) status for RPG. 



Creating a Bootable PO Tape via DEF 

To facilitate creating a new bootable PO tope that matches o site's own requirements, 
two jobs are provided in the .SUPPORT account: $XDEF.MINI and $XDEF_FULL. The jobs, 
intended to be run In botch mode, perform these functions: 

o $XDEF_MINI re-DEFs the "mini" portion of the PO tope, that is. just the portion of 
the PO tape that is bootable and contains the TIGR commands and patches for the 
monitor and system processors and language processors. 

o $XDEF_FULL re-DEFs the entire PO tope set, including the bootable portion and the 
processor reels. A system manager may need to re-DEF the entire PO tope set. if, 
for example, a maintenance release of a processor has been received. 



Using $XDEF_MNI and $XDEF_FULL 

Several points must be considered when using the $XDEF.MINI or $XDEF_FULL jobs: 

o The density defaults, resource requirements and limits may need to be adjusted to 
what is appropriate for the system monager's site. 
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o DEF's MINI.ID command allows the system manager to create a unique bootable tope 
that will identify Itself at boot time (through AARDVARK I/O to the console) and 
after booting through the use of IWHAT.X. It is recommended that the mini ID be 
specified as the patch revision level (which is unique over a 16-year span) to aid 
in remote debugging efforts. 

o Certain files in accounts .SUPPORT and . :C00PRC are used by the $XDEF.MINI and 
$XDEF.FULL jobs, as detailed in the JCL. 

In addition, prior to DEFing a full PO tape set, the following steps must be taken: 



IPIG 

CR DP#SYS . : SYSGEN G«1 6000 . WfR-me 

MADADD DPfSYS. : SYSGEN 

END 

IPRIV ALL ...otherwise you miss the IDS products 
IPCL 

CA LT#CP6P02[|CP6P03. . .] TO .: SYSGEN 

CA newprocessor .otheraccount OVER .:SYSGEN 



CA :FEP.?. I inkaccount OVER SYSGEN 
COPY M:MON.:SYS OVER M:MON. :C66PRC 
END 



Sample tXDEFJtm Job 

The following extended example illustrates modifying and running a $XDEF_MINI job. This 
example shows two significant changes to the $XDEF_MINI job which affect DEF's PATCH 
command : 

o An up-to-date patch file is named in DEF's PATCH command. 

o A TIGR deck reflecting the site's specific hardware configuration is merged into the 
file named in DEF's PATCH command. (This is the T I GR.REL. SUPPORT file modified in 
the preceding examples.) 



I C $XDEF_MI NI . SUPPORT TO $XDEF_TEST . MYACCT 

. .COPYing 
IE $XDEF_TEST 
EDIT C66 HERE 
♦TYl-4 

1.666 IDEFAULT SITE-ID-'THE C ,SITE-NAME«'THE C . 'TAPE1 '«'CP6P01 ' , i 

1.566 IPATCHWEEK-666 

2.666 NOB PRI07, RERUN 

3.666 IRES MT»1 ,MEIyN166.TIME-16 

4.666 I LIMIT FPOOLS-36 
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This job creates a single-reel bootable PO tape, to be used i 


n 






conjunction with existing reels CP6P02, CP6P03» etc... The 








primary reason for making such a tape is to place new patches 


on 






the bootable portion of the PO tape for application to the monitor 






and system processors (found on CP6P02. etc). 




♦RRl-4 






1 


000 


IDEFAULT SITE-ID=* JJ • *S CP-6* ,SITE-NAME»* JJ ' 'S CP-6* . ; 




1 


500 


1 *TAPE1«'CP6P01 ' . PATCHWEEK=224 




2 


000 


!JOB PRI(^7. RERUN 




3 


000 


IRES MT«1 ,MEIi/^100.TIME*10 




4.000 


1 LIMIT FPOOLS=30 








The site ID has been changed, site name hos been changed, and 


0 






change has also been made to PATCHWEEK«. 




12 


000 


)M MOUNT |TAPE1 — RING IN FOR SITE-NAME PO TAPE 




13 


000 


! DEFAULT DEN=1600 




14 


000 


!SET M$PO FT|TAPE1 ,ORG«FREE 




15 


000 


!DEF 




16 


000 


PO C00.NOFILES 




17 


000 


MINI. ID *PATCHWEEK* 




18 


000 


DENSITY DEN 




19 


000 


NOLIST 




20 


000 


SITEID *SITE-ID' 




21 


000 


SITENAME 'SITE-NAME' 




22 


000 


FIRMWARE FIRMB3. :C00PRC 




23 


000 


BOOT AARDVARK. :C00PRC 




24 


000 


MON MrMON. :C00PRC 




25 


000 


MHJIT MHJIT. :C00PRC 




26 


000 


XDLT XDELTA. :C00PRC 




27 


000 


XDLTLS XDELTALS. :C00PRC 




28 


000 


GHOST 1 GH0ST1 . :C00PRC 




29 


000 


G1HJIT G1HJIT. :C00PRC 




30 


000 


PATCH :C00PATCH. SUPPORT 




31 


000 


INSTALL SXINSTALL. SUPPORT 




32 


000 


END 




* EOF hit after 32.000 




♦EX :C00PATCH. SUPPORT 




•rT0-9999,/ITIGR/ 




450 


AAA 


ITIGR "L66 




• EOF hit after 3337.000 








The system manager examines : C00PATCH . SUPPORT , and determines 


that 






ITIGR "L66 starts on line 450.000. 




IC :C00PATCH. SUPPORT TO :C00PATCH.TEST.MYACCT 




. .COPYing 








: C00PATCH . SUPPORT is copied to a file in the system manager's 


own 






account . 




! E : C00PATCH.TEST . MYACCT 




EDIT 000 HERE 




♦TY450 






450 


000 


ITIGR "L66 




♦TN23 








451 


000 


"TIGR REL" 




452.000 


AUTOCONFIG 




453 


000 


FEP NAME-FEP1 , IOM#-0,CHAN-33 




454 


000 


FEP NAME-FEP2,IOM#-0,CHAN-34 




455 


000 


FEP NAME«FEP3,IOMf=0.CHAN-35 




456 


000 


FEP NAME«FEP4,IOMiif-0,CHAN-36 




457 


000 


MON ; 




458.000 


SITE»*CP-6' ,; 




459 


000 


SAL-*»»* CP-6 AT YOUR SERVICE',; 
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460 . 000 I OCACHE-500 . ; 

46 1 . 000 STEALPGS«( 1 5 . 30) . ; 

462 . 000 QUEUE- (90 . 90) . ; 

463.000 USERS-200.; 

464.000 DOLIST-50, ; 

465.000 DEVMAX«300.; 

466.000 PATCH-600. ; 

467.000 ENO«(4.10). ; 

468.000 CFU-(1 .20). ; 

469 . 000 SPSPACE-20 . ; 

470 . 000 SPAUTOSPACE-1 00 . ; 

471 .000 SPROC-( LOGON. CP). ; 

472 , 000 SPROOf IBEX .CP) , ; 

473.000 SPROC-(DELTA,DB). ; 
*DE 

• 23 records delated 



23 records ore deleted (the first port of the issued TIGR deck). 



*TN10 

474.000 SPROC«(IDS.AS). ; 
475 . 000 SPROC- ( : SHARED^COBOL .LI).; 
476 . 000 SPROC-( : SHARED^SYSTEM , L 1 ) . ; 
477 . 000 SPROC»( : SHARED.COIM)N . LI ) 
478.000 !RUM "COO 

479.000 RUM : SHARED.COB . UTS-05/04/84 16:11:40.47 
480.000 RUM :SHARED_COBOL.UTS«04/20/84 10:49:27.44 
48 1 . 000 RUM : SHARED.COMMON . UTS-04/ 1 9/84 1 4 : 28 : 49 . 1 0 
484.000 RUM :SHARED_RPG,UTS-O5/05/82 15:49:56.30 
483.000 RUM iSHARED^SYST EM. UTS-04/ 13/84 16:25:32.02 
♦DE474-477 

* 4 records deleted 



•TP10 
441 



The lost four records of the issued TIGR deck which designate 
SPROC options ore deleted. 



"DEG COO 05/25/84 2734 
"DEG COO 05/25/84 28-34 
DEG COO 05/25/84 29-34 



000 " STUFF SCRATCH AREA WITH LOHER CASE IF QUOTED/OCTAL 
LEXEME #12253 
442.000 M F+.1226 TRA O (TRA F+.1253) 
443.000 MO LDP1 PTR 
444.000 M e .000100101500 "MRL 
445.000 M • .200010000005 " SOURCE 
446.000 M 0 .100000000005 " DEST 
447.000 M O $RI 
448.000 KILL DEF PTR 
449.000 KILL DEF F 
450.000 !TIGR "L66 
•DE450 

* 1 records deleted 



2253 
2253 
2253 



DEG COO 05/25/84 30-34 #12253 
DEG COO 05/25/84 31-34 #12253 
"DEG COO 05/25/84 32-34 #12253 
"DEG COO 05/25/84 33-34 #12253 
"DEG COO 05/25/84 34-34 #12253 



Line 450.000. which invokes TIGR. is deleted. 



♦MERGE TIGR.TEST.MYACCT. 0-999 INTO :C00PATCH.TEST.MYACCT,450. .01 

• EDIT stopped 

• MERGE started 

• EOF hit after 50.000 

• Done at 450.500 

• 51 records moved 

• MERGE done 



The system manager merges the TIGR file into the system monager 
owned version of the rCOOPATCH file. 
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»TY 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 

450. 
*END 



000 ITIGR "MY cm TI6R DECK 
010 CPU P0RT#«2 
020 CPU P0RTf«3 
030 lOM PORTf«0 

040 CONSOLE NAME-SC01 . I0M#«1 .CHAN-30 

050 DISK ; 



060 
070 
080 
090 
100 
110 
120 
130 
140 

150 TAPE 
160 
170 
180 



MPC.MPCNAME-DC01 .MODEL-MSP06e0 
LA ; 

IOM#-0.CHAN»8-11 



DEV 



NAME»DP01 .MODEL«(MSU0451 ,MSF0007) . DEV|»1 , SYSTEM 
NAME=DP02. MODEL* CMSU0451 .MSF0007) .DEVj ^2 
NAME=DP03.MOOEL=( MSU0451 ,MSF0007) .DEVj ^3 
NAME'DP23.MODEL»=(MSU0501 ,MSF0015) .DEVf»23 
NAME»DP25.MODEL»(MSU0501 ,MSF0015) . DEV|«25 , STATU&OOWN 



NAME=MT01 ,MODEL=(MTU0630.MTF0636) .DEV#=1 
NAME-MT02 . MODEL=( MTU061 0 . MTF0608) . DEVf «2 
NAMEHylT03 , MODEL«(MTU061 0 , MTF0608) . DEVf »3 



MPC.MPCNAME>TC01 ,MODEL»MTP0610 
LA ; 

IOM#«0.CHAN-16-17 ; 

190 DEV 
200 
210 
220 

230 UNIT ; 
240 MPC,MPCNAME«UC01 ,MODEL=URP0600 ; 

250 NAME=LP01 ,M0DEL=(PRU1 200 ,PRB0600) . IOM#=0.CHAN=24.OUT.SYMBIONT; 

260 NAME»CR01 . MODE L»(CRU0 501 ) , IOM|-*0,CHAN»26. IN.SYMBIONT 

270 FEP NAME-FEP1 .IOM|=0.CHAN=33 
280 MON ; 

290 SITE«*JJ' 'S CP-6* , ; 

300 SAL«**** JJ"S CP-6 AT YOUR SERVICE',; 

310 MTDFLT-(1600),; 

320 IOCACHE»500. ; 

330 STEALPGS«(15,30), ; 

340 QUEUE«(90,90).: 

350 USERS-75,; 

360 DOLIST-50.; 

370 DEVMAX«100,; 

380 PATCH-600,: 

390 ENQ-(4,10).: 

400 CFU-(1.20),; 

410 SPSPACE-20.; 

420 SPAUTOSPACE-50. ; 

430 SPROC-( LOGON . CP) . ; 

440 SPROC-(IBEX,CP), ; 

450 SPROC-fDELTA . DB) , ; 

460 SPROC«( IDS.AS). ; 

470 SPROC-( : SHARED^COBOL . LI ) . ; 

480 SPROC-( :SHARED_SYSTEM, LI ) . ; 

490 SPROC-( : SHARED.COMMON .LI),; 

500 SPROC«( : SHARED_RPG , LI ) 



The merged records are displayed. 

IE $XDEF.TEST 
EDIT C00 HERE 
♦AP 

33.000 
♦TP23 

10.000 i*' monitor and system processors (found on CP6P02, etc) 
1 1 000 I *' 

12.000 IM MOUNT #TAPE1 — RING IN FOR SITE-NAME PO TAPE 

13.000 {DEFAULT DEN-1600 

14.000 ISET M$PO FT#TAPE1 ,ORG-FREE 



(cont. next page) 
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15. 


000 


IDEF 






16. 


AAA 


PO C00,NOFILES 






17, 


000 


MINI.ID 'PATCHWEEK' 






18. 


000 


DENSITY DEN 






19. 


000 


NOLI ST 






20 


000 


SITEID 'SITE-ID* 






21 


000 


SITENAME *SITE-NAME' 






22, 


000 


FIRMWARE FIRMA3. :C00PRC 






23 


000 


BOOT AARDVARK. :C00PRC 






24 


000 


MON M:MON. :C00PRC 






25. 


000 


MHJIT MHJIT. :C00PRC 






26. 


000 








27. 


000 


XDLTLS XDELTALS. :C00PRC 






28 


000 


GHOST 1 GHOST 1 . :C00PRC 






29 


000 


G1HJIT G1HJIT. :C00PRC 






30 


000 


PATCH :C00PATCH. SUPPORT 






31 


000 


INSTALL $XINSTALL. SUPPORT 






32.eee 


END 






*RR30 










30 


000 


PATCH : C00PATCH_TEST . MYACCT 










The system manager changes 


1 i ne 30. C 


100 to *C00PATCH TEST 


* 

• END 










! BATCH $XDEr_TEST 










As a finol step, the system 


manager 


batches the modified file to 






create a new PO tape. 
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Module 4-1 

Introduction to Project and User Authorization 



The system manager is responsible for enabling, monitoring and maintaining use of the 
CP-6 system. The many users of the CP-6 system must be controlled and the ultimate 
responsibility for that control lies with the system manager. The system manager needs 
to have a plan for controlling who will use the system and how. 

In a typical installation, management of system use is facilitated by dividing use of 
the CP-6 system into a hierarchy of projects, each project consisting of a defined set 
of users. The system manager can administer projects directly, or the system manager 
can delegate responsibility to manage projects to one or more project administrators. 
If project administrators are used, the system manager defines who they are and what 
they can do. 

This module describes the process which authorizes projects and logon users on the CP-6 
system. Module 4-2 contains details and examples of project authorization. Module 4-3 
contains details and examples of user authorization. Modules 4-2 and 4-3 are 
self-contained introductions to project and user authorization, respectively. Those 
modules con be distributed to appropriate staff as stand-alone tutorials. As such, an 
expanded version of some of the material presented here is repeated in those modules. 
Also, some material not presented here appears in both of those modules. 

The tasks of these authorization processes involve the use of the SUPER and Packset 
Initializer Ghost (PIG) processors. 

The system manager controls access to the CP-6 system in two different ways: 

1. Through logon account authorization, which enables users to logon to and use the 
CP-6 system. 

2. Through file management account authorization, which enables creation and 
maintenance of permonent files on the CP-6 system. 

Note that these outhori zat ions are separate. Therefore, a user can be authorized to log 
onto and use the CP-6 system by means of a logon account, but not to maintain any files 
in the logon account. (Likewise, a file management account can be created to contain 
files only — no user can then tog onto thot file management account.) 

The SUPER processor is used for logon account authorization. SUPER is used to create, 
modify, list and remove (delete) projects and logon users. For each project and each 
user, the authorization includes a name, the system resources that will be used, and any 
speciol privileges. 

The PIG processor is used for file monagement authorization. PIG is used to establish 
project pocksets and user file management account(s). The PIG processor can be accessed 
from the SUPER processor directly so that some file management outhori zat ion control 
functions can be accomplished from the SUPER processor. 

The modules in this section describe the logon authorization processes for projects and 
users and describe how to set up file management accounts from SUPER. These modules 
assume that the system environment in which the projects and users are created has 
already been established. For example, these modules describe establishing file 
management accounts in the context of on already initialized packset. The reader of 
this manual will be interested in module 1-1, which describes some general environment 
planning considerations, including grouping users, and the reader will want to refer to 
the CP-6 System Support Reference Manual (CE41 ) for details on all the SUPER commands 
and options introduced in this module and in module 4-2 and 4-3. 
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These modules present user authorization as occurring in o single record in on attempt 
to simplify the conceptual presentation. In fact, the user authorization Information is 
contained in two system files: the :USERS and :HLP files. 



Authorization Process 

Authorization is the process of creating authorization records that identify projects 
and logon users and that specify the capabilities and limits that will be assigned to 
them. A similar process is used to create projects and to create logon users. Separate 
authorization records are built for each project and each user. Authorization records 
are created and mointained via SUPER commands. The fields in an authorization record 
ore changed via SUPER options and suboptions. (Module 4-2 describes how project 
authorization records are built and maintained. Module 4-3 describes how user 
authorization records are built and maintained.) 

Each CP-6 system is installed with five authorization records already in it: 



Authorization Record 


Purpose 


DEFAULT 


The system default user authorization 
record. 


OEFAULTP 


The system default user authorization 
record for projects. 


:SYS,LJS 


An initial logon user record for the 
system manager. 


: FED, SUPPORT 


A logon user record for Honeywell field 
engineering support staff. 


:SYSTAC,LADC 


A logon user record for Honeywell CP-6 
software support staff. 



Defoult records ore provided with each CP-6 system to simplify the task of 
authorization. In o project or user authorization, each record field not explicitly 
assigned a value through the corresponding SUPER option or suboption is set to the value 
of the corresponding field in the default authorization record. One default record. 
DEFAULTP. is used to simplify the task of assigning attributes to users assigned to a 
project. The other defoult record. DEFAULT, is used to simplify the task of creating 
logon users who are not assigned to a project. 

As part of CP-6 system initialization, the system manager will use the :SYS.LJS record 
OS the logon user record until the system manager builds on authorization record. 
Typically, at this time also, the system manager will consider whether to modify the 
contents of the system-supplied DEFAULT and DEFAULTP record. At least the HSET field in 
the DEFAULT and DEFAULTP authorization records should be modified. If they ore not, the 
system pockset (|SYS) will be assumed as the default pockset. Once the system manager 
builds the own user authorization record and once the field support personnel hove 
completed testing of the system, the iSYS.LJS authorization record must be deleted from 
the system. Then, the process of building project and user authorization records 
begi ns. 
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Default Records 

The DEFAULTP. DEFAULT and the user authorization records created through SUPER all 
contoin an identification and the following classes of authorizations: 



Authorization Class 


Descr ipt ion 


Budget 


Establish dollar usage limits and 
accounting methods. 


FEP 


Establish miscellaneous, privilege and 
processor privilege authorizations for 
front end processors (FEPs). 


Mi seel laneous 


Establish resource utilization and other 
limits, and tailor the CP-6 environment. 


Privi leges 


Grant capabilities not available without 
special authorization. 


Processor Privileges 


Grant capabilities to use system 
processors. 


Services 


Establish service limits. 



Authorization Record Contents 

This section describes an authorization record by listing the contents of the system 
default authorization record (used to assign default values if there is no project 
default authorized record). Since all authorization records contain the fields in the 
system default record, this listing introduces the reader to the principal contents of 
any authorization record. This discussion also identifies the SUPER options ond 
suboptions used to modify the contents of these fields. However, no attempt is made to 
describe each of the fields. Modules 4-2 and 4-3 describe some of the fields; all of 
the fields in an authorization record ore described in the section "SUPER: System 
Administration" in the CP-6 System Support Reference Manual (CE41). However, this 
discussion does indicate the SUPER options and suboptions used to modify the fields 
introduced in this section. 



Each field in the record is assigned a name. Values ore listed with the ossocioted 
field name. If the field contains a null value, the field name is listed with a blank 
value. Some fields have multiple entries for the different host ond FEP modes. The 
host modes are: 



B: Botch 

G: Ghost 

0: On-line 

T: Transaction Processing 



The FEP modes ore: 



U: User 

C: Comgroup 

H: Handler 

G: Ghost 



The first lines in the record listing list the default budget and accounting 
information, as follows: 
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ACHARGES MCHARGES BKACCESS BUDLIM ICHARGE PCHARGE BLINDACCOUNTING 

$e.ee none yes no yes yes no 

These fields are changed via the BUDGET authorization 
subopt ions. 



The first field on the next line of the record listing identifies the project 
odmi ni st rotor and the next field on that line identifies the default home pockset 
(HSET). The rest of the fields on that line and on the next several tines of the record 
ore environment specific information including: 

o the (default) terminal profile (PROFILE). 

o whether a password is required to initially logon (PASSWORD). 

o the identification of the (default) workstation, which usually describes where 
printed output will go (WSN) . 



PROJECT ADMIN HSET NATIVEL PASSWORD PROFILE WSN 

NONE SYS NO TTY LOCAL 

OUTPUTPRIO STEPACCNT ♦S.ACCOUNTING EXPIRE UAX EXPIRE DEF BATNUM 
7 NO NO NEVER NEVER -1 

PROJECT ADMIN can be changed via the SUPER command MODIFY 
PROJECT. The other fields ore changed using SUPER options 
that ore the some as the field names except for EXPIRE MAX 
and EXPIRE DEF which are both changed through the EXPIRE 
opt ion. 



The following record fields describe the nine fields on print out banners. 
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BANNER 1 


ALTERABLE 


BANNER2 ALTERABLE BANNER3 ALTERABLE BANNER4 ALTERABLE 


YES 




YES YES YES 


BANNERS 


ALTERABLE 


BANNERS ALTERABLE BANNER? ALTERABLE BANNERS ALTERABLE 


YES 




YES YES YES 


BANNERS 


ALTERABLE 




YES 












BANNER 1 




be altered and no banner field contains 






any text. 


BANNER2 
o 






o 

0 

BANNERS 






These fields 


are changed through the SUPER option BANNERTEXTn. 



The following fields define the (default) command processor commands that are to be 
executed at logon. 





ALTERABLE SETUP 




B: 


YES 


By system default, SETUP commands con be 


G: 


YES 


ol tered. 


0: 


YES 




T: 


YES 






SETUP 




B: 




By system default, no SETUP commands are 


G: 




executed at logon time. 


0: 




T: 








These fields ore 


changed through the SUPER option SETUP. 
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The following fields define additional environment and resource attributes. 





Pi LLirlv 


MCJn MAA 


MEM DEF TIME MAX 


TIME DEF QUAN PRIOB 


D 


1 


511 


64 9999 


ie e 0 




1 


511 


256 9999 


9999 e 0 


0 


1 


511 


128 9999 


9999 0 0 


T 


1 


511 


256 9999 


9999 0 0 




CPROC 




LAST CPROC 




B 


IBEX 








G 


IBEX 








0 


IBEX 








T 


IBEX 










These 


fields 


are changed using SUPER options that are the same 




as the field 


names except for MEM MAX and MEM DEF which are 




both 


changed 


through the MEMORY 


option, and TIME MAX and TIME 




DEF which are 


both changed through the TIME option. 



The following fields contain default service limits. 



MAX LO 
99999 
99999 
99999 
99999 



DEF LO 
1000 
99999 
99999 
99999 



MAX PO 
99999 
99999 
99999 
99999 





DEF PO 


MAX DO 


DEF DO 


MAX TDIS 


DEF TDIS 


MAX PDIS 


DEF PDIS 


MAX 


B: 


100 


99999 


50 


99999 


2000 


99999 


99999 


31 


G: 


99999 


99999 


99999 


99999 


2000 


99999 


99999 


31 


0: 


99999 


99999 


99999 


99999 


9999 


99999 


99999 


31 


T: 


99999 


99999 


99999 


99999 


2000 


99999 


99999 


31 



DEF FPOOLS MAX PRIO DEF PRIO 

B: 10 7 7 

G: 10 7 7 

0: 10 7 7 

T: 10 7 7 



The values In these fields can be changed via suboptions 
specified after the SUPER option SERVICES has been specified. 
(See the SUPER User Authorization Options and Suboptions 
table in Module 4-3.) 



The following fields contoin odditionol environment fields: 
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ACCESS 




B: YES 




G : NO 




0: YES 




T: NO 




F: NO 




KEY 




NONE 




The values in each of these fields can 


be changed via the SUPER 


options ACCESS and KEY» respectively. 


The F: field enables 


front— end access. 





The following fields contoin the set of (default) privileges: 



PRIVILEGES 

ASAVE D ISP JOB CFEP EXMM EXPM FMDIAG FMREAD FMSEC GPP lOQ lOQI^ 



6: 


NO 


NO 




NO 


NO 


NO NO NO NO 


NO 


NO 


NO 


G: 


NO 


NO 




NO 


NO 


NO NO NO NO 


NO 


NO 


NO 


0: 


NO 


NO 




NO 


NO 


NO NO NO NO 


NO 


NO 


NO 


T: 


NO 


NO 




NO 


NO 


NO NO NO NO 


NO 


NO 


NO 




JIT 


MAXM 


MFEP 


MSYS 


PM 


SPCLMM SYSCON SYSLOG TND 








B: 


NO 


NO 


NO 


NO 


NO 


NO NO NO NO 








G: 


NO 


NO 


NO 


NO 


NO 


NO NO NO NO 








0: 


NO 


NO 


NO 


NO 


NO 


NO NO NO NO 








T: 


NO 


NO 


NO 


NO 


NO 


NO NO NO NO 









The values in these fields con be chonged via suboptions 
specified after the SUPER option PRIVILEGES has been 
specified. (See the SUPER User Authorization Options and 
Suboptions Table in Module 4-3.) 



The following fields contain the set of default processor privileges: 
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PROCESSOR PRIVILEGES 












CNTRLC 


CNTRLD EFT EL 


NETCON 


LABEL 


P ADM IN 


PIGC PIGD RATES 


REPLAY 


D 
D 


NO 


NO NO NO 


NO 


Kin 


NO 


NO NO NO 
nVii TTSj nv/ 


NO 




Kin 




NO 


un 


NO 


KIO NO NO 
Tfsj nv^ 


NO 




NO 


NO NO NO 


NO 


klA 


NO 


NO NO NO 

nv/ 


NO 


T 

1 


NO 


NO NO NO 


NO 


Kin 


KIO 


NO KIO KIO 
Tfu rfu 


NO 




SPIDERC 


SPIDERD SUPER 


SUPERA 


SUPERD 


SUPERF 


SUPERS VOLINIT 


SYSCON 


Q 
O 


NO 


NO NO 


NO 


NO 


NO 


NO NO 


NO 


\9 


NO 


NO NO 


NO 


NO 


NO 


NO NO 


NO 


A 
V/ 


NO 


NO NO 


NO 


NO 


NO 


NO NO 


NO 


T 


NO 


NO NO 


NO 


NO 


NO 


NO NO 


NO 




PIGETTE 














B 


NO 














G 


NO 














0 


NO 














T 


NO 
















The 


values in these 


fields 


can be 


changed 


via suboptions 






specified after the 


SUPER option PPRIVILEGES has been 






specified. (See the SUPER User Authorization Options and 






Suboptions Table in lylodule 4-3.) 









The following fields contain the set of (default) allocatable system peripherals: 



RESOURCES 

MT DP 
B: 4 '4 
G: 4 4 
0: 4 4 
T: 4 4 

The values in these fields con be changed via suboptions 
specified after the SUPER option RESOURCES has been specified. 
The SUPER option RESOURCES is used to allocate peripherals 

itape drives, tine printers, cord punches ond so on). 
See the SUPER User Authorization Options and Suboptions 
Table in Module 4-3.) 



The following field contains the default file isanageiiient account inforisot Ion: 
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FACCOUNT 

rXP-00e27-0 Packset (packsetid) not currently mounted. 

File management account information is assigned and 
maintained via the CP-6 PIG processor. PIG con be accessed 
through the SUPER option FACCOUNT so that matching logon account 
and file management account information can be processed as part 
of the some activity. However. PIG will still need to be 
entered to make the appropriate entry in the Master Account 
Di rectory . 



The following fields contain FEP resource, privilege and processor privilege 
information. Note thot white front end (FE) processor privileges (FE PROCESSOR 
PRIVILEGES) can be set in SUPER, they are not supported currently in the system. 
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FE-MFPRG FEHi4AX-ACCT-MEM FE-OBACCN 








255 9999 










FE-MINTS FEHylAX-TIME FE-4(IAX-4IEM FE-BILLING 




U: 


0 9999 128 


1 






C: 


0 9999 128 


1 






H: 


0 9999 128 


1 






G : 


0 9999 128 


1 








FF— PR T V T L FCFS 










FXMM FXPM FMRFAD FUSFC GPP 




iyiSYS SPCLMM SYSLOG TNO 


INTCON 


U: 


NO NO NO NO NO 


^NO* 


NO NO NO NO 


NO 


C: 


NO NO NO NO NO 


NO 


NO NO NO NO 


NO 


H: 


NO NO NO NO NO 


NO 


NO NO NO NO 


NO 


G : 


NO NO NO NO NO 


NO 


NO NO NO NO 


kin 




CO SNAP SCREECH 








U: 


NO NO NO 








C: 


NO NO NO 








H: 


NO NO NO 








G: 


NO NO NO 










FE PROCESSOR PRIVILEGES 










CNTRLC CNTRLD EFT EL NETCON 


LABEL PADMIN PIGC PIGD RATES 


REPUY 




NO NO NO NO NO 


NO 


NO NO NO NO 




c • 


NO NO NO NO NO 


NO 


NO NO NO NO 


MO 


n • 


NO NO NO NO NO 


NO 


NO NO NO NO 


kin 
nv 


ft* 


NO NO NO NO NO 


NO 


NO NO NO NO 


hJT) 




SPIDERC SPIDERD SUPER SUPERA SUPERD 


SUPERF SUPERW VOLINIT 


SYSCON 


U: 


NO NO NO NO 


NO 


NO NO NO 


NO 


w • 


NO NO NO NO 


NO 


NO NO NO 


NO 


H: 


NO NO NO NO 


NO 


NO NO NO 


NO 


G: 


NO NO NO NO 


NO 


NO NO NO 


NO 




PIGETTE 








U: 


NO 








C: 


NO 








H: 


NO 








G: 


NO 










The values in these fields can be changed via the approprlote 




SUPER FEP options and suboptions (see the SUPER User Authorization 




Options and Suboptions Table 


in Module 4-3.) 
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Using SUPER 

SUPER can be run as a batch or online job. Normally, SUPER is run as an online job. It 
is invoked by the command ! SUPER. When SUPER is invoked, command mode is initiated ond 
SUPER commands are issued. The online prompt in command mode is CMD*. 

When SUPER commands are issued, they cause a sub I eve I mode, the option mode, to be 
entered. The online prompt in option mode is OPT*. 

When some SUPER command options are issued, they cause a sub-sublevel mode, the command 
suboption mode to be entered. The online prompt to enter command suboptions is SUB*. 
The following example illustrates online prompting. 



1 SUPER 






**♦ CP-6 SUPER C00*** 




CMD*CREATE ABC001 .473 JONES 


OPT*HSET-USER 






OPT*PASSWOR[>«00 1 ABC 




OPT*PROFI LE-VIP7205 




OPT*WSN=REMOTE 






OPT*BUDGET 


< — 


Introduces suboption mode. 


SUB*MCHARGES=200 




SUB*BKACCESS»NO 






SUB* 


< — 


Suboption mode terminated by a null line. 


OPT*FACCOUNT 


< — 


Introduces suboption mode. 


SUB*GR«50 




SUB* 


<— 


Suboption mode terminated by a null line. 


OPT*PRIV 


< — 


Introduces suboption mode. 


SUB*ASAVE O.B.G 




SUB* 


< — 


Suboption mode terminated by a null line. 


OPT* 


< — 


Option mode terminated by a null line. 


CM)* END 

1 


< — 


SUPER terminated by the END command. 



The next prompting level (down) is always initiated automatically. The previous 
prompting level (up) is returned to by responding to a prompt with END or a null line 
(i.e., either an immediote RETURN or a blank line). END must be specified in response 
to a commond level prompt to terminate SUPER processing. 

In most cases, multiple options and suboptions may be specified on the same line. If 
this is done, entries ore separated by a semicolon. 

If SUPER is run in the batch mode, the user must anticipate level changes and exit 
properly from each level before entering a higher level option or command. 
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Module 4-2 

Project Administration 



Projects ore defined to provide a structure within which logon users are defined. Each 
project is a control iing element, arranged in a simple hierarchy; each project is 
subject to the resource limitations of the project above it, and may further restrict 
the resources availoble to the project below it. As these resources ore consumed, they 
ore charged against each project all the way up the hierarchy. 

The following figure illustrates the hierarchical structure of project administration. 



System Monager 
defines autonomous projects 



Project A 

Project Administrator 



Project B Project C 

Project Administrator Project 

Admi n i st rotor 



Figure 2. Project Structure 
Within each project, logon users are authorized, as illustrated in the following figure. 



Project A 



Project B 



User 1 User 2 User 3 User 4 User 1 User 2 User 3 User 4 



Figure 3. Project/User Structure 



CP-6 users may then logon and use the CP-6 operating system. No user may be a member of 
more than one immediate project. In this cose* eoch project is independent of the 
others. 



f»rftft Aft 
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Project A 



User A1 



User A3 



User A2 



Project B 



User B1 



User 83 



User 82 



Project C 



User CI 
User C2— 



Project CA 



User CA1 User 
CA2 



Figure 4. Multilevel Project Structure 



Initiolly, the system manager must define projects with project administrators who can 
create subprojects. (If project administrators with project creation authorization are 
not created, then the system manoger must define all projects in the system.) Each 
project is defined by: 

o Assigning the project a logon id, 

o Defining the maximum number of members allowed in the project, 
o Defining the packset that will hold the project's disk storage, 
o Defining the project default record. 

o Defining the project administrator, if appropriate. If no project administrotor is 
created, the system manager is the project administrator. 

In practice, each project administrotor is on occounting center. At definition, each 
project administrator is ot located o set of resources the major items of which are 
budget dol loVs and disk space. 

The project odmi nist rotor does not hove a free hand. The system manager imposes the 
following const roints when creating the project: 

o The number of logon IDs per project. 

o The number of file management accounts per project. 

o A moximum set of privileges, services, ond resources that may be given to project 
members. At the system manager's discretion, the project administrator may further 
restrict this set or be forced to give each member exactly the same ottrlbutes 
specified for the project administrotor. 

o The total amount of disk space that may be used by alt project members. 

In addition, the system monoger can preestoblish o naming convention for logon IDs and 
file management accounts 
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Creating Projects 

Once SUPER has been invoked, creation of a project is initiated by entering the 
following SUPER command: 

CREATE PROJECT account, name 

The values entered for account and name are the logon id that will be used for 
administration of this project (if a project administrator is created, the logon id of 
the project administrator). The account value consists of up to 8 alphanumeric 
characters and the name value consists of 1-12 olphanumeric characters and the symbols $ 
and : . 

This command initiates the project authorization mode. The online prompt to enter 
project level options is PROJ«. Note that in project administration there are four 
levels of data entry and four prompts: 



Data Entry Level 


Prompt 


The SUPER command level 


CMD* 


The project level 


PRO J* 


The option level 


OPT* 


The suboption level 


SUB* 



The following table summarizes all data entry levels except the command level and lists 
the options that can be specified at each level. 



Table 3. SUPER Options 



Project Level Option Level 



Suboption Level 



ACCOUNTS 
ACHARGES 
ADMINISTRATOR 
DEFAULT • 



MCHARGES 
PACKSET 



See the next table. 

The same options as 
ore oval labte for 
ADMINISTRATOR are 
avG I lable for 
DEFAULT except that 
FACCOUNT and its 
suboptions are not 
available for DEFAULT. 



ACCOUNTS 
ATTRIBUTES 



GRANULES 
SKELETON 



Only the BUDGET 
suboptions are 
available. They 
are the some as 
for ADMINISTRATOR. 



The some sub- 
opt ions as are 
aval 1 able for the 
ADMINISTRATOR 
FACCOUNT option 
ore aval lable for 
the ATTRIBUTES 
opt ion. 
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Table 3. 


SUPER Options 


(cont . ) 


Project Level Option Level 


Subopt i on 


Level 


PROJECTS 






REMOVE PACKSET 







The following table lists the ADMINISTRATOR options and subopt ions. These user 
author i zot ion options and ore described further in Module 4-3. 



Table 4. ADMINISTRATOR Options and Subopt ions 



Opt ion 



Subopt ion 



ACCESS 

BANNERTEXT 

BATNUM 

BILLING 
BUDGET 



CPROC 

EXPIRE 

FACCOUNT 



Note: The BATNUM option can be 
set in SUPER but is currently not 
supported in the system. 



ACHARGES 

BKACCESS 

BLINDACC0UNTIN6 

BUDLIM 

I CHARGE 

MCHARGES 

PCHARGE 



[NOlACUP 

[NOJBACKUP 

CGMEM 

[NOlCHECKWRITE 

[ NO J DAT ACHECKWR I TE 

DEFAULTBACKUP 

GRANLIM 

[NOlMERGEACCESS 
no' NEWFDS 
NOJSHELFTIME 
OWNER 
NOT ] PROTECTED 
NO] PURGE 
NOJSTOI* 

File Access options: 
DELR, DELFILE, 
EXECUTE. FITMOD, 
NOLIST. READ. 
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Tobie 4. ADMINISTRATOR Options and Suboptiona (cont.) 

Opt i on Subopt ion 



REATTR. SCRATCH 
UPDATE, WNEW. 
WRITE 
Account occoss: 
CREATE, NONE 



FEBILLING 

FEDBACCN 

FEMACCTMEM 

FEMFPRG 

FEMINTS 

FEMMEMORY 

FEMTIME 

FEPPRIVILEGE CNTRLC 
CNTRLD 
EFT 
EL 

LABEL 

NETCON 

PADMIN 

PIGC 

PIGD 

PIGETTE 

RATES 

REPLAY 

SPIDERC 

SPIDERD 

SUPER 

SUPERAUTH 

SUPERD 

SUPERFORM 

SUPERWSN 

SYSCON 

VOLINIT 



Note: The FEPPRIVILEGE 
subopt ions may be set 
in SUPER but currently 
are not supported in 
the system. 



FEPRIVILEGE CO 

Exm 

EXPM 

FMREAD 

FMSEC 

GPP 

INTCON 

UAXM 

MSYS 

SCREECH 

SNAP 

SPCLMM 

SYS LOG 

TND 



FEPSEUDO One or more FEP pseudo resources. 
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Tabl« 4. ADMINISTRATOR Options and Suboptiona (cont.) 


Opt ion 


Subopt i on 


FERESOURCES 


One or more FEP resources. 






KEY 




LAST rppor 




















PPRivT 1 mr 


wn 1 i\i.w 




wn 1 




FFT 




ri 








rib 1 wvn 




PADMIN 




PIGC 




PIGD 




PICETTE 




RATFS 

1 CO 




RFPt AY 




Or I vbl^w 












ei jprpAi ITU 








CI jprprnpu 








o 1 wwvn 










PRIVILEGE 


ASAVE 




CFEP 




D ISP JOB 




EXMM 




EXPM 




FMDIAG 




FMREAD 




FMSEC 




GPP 




lOQ 




lOQW 




JIT 




MAXM 




MFEP 




IISYS 
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Table 4. ADMINISTRATOR Options and Suboptions (cont.) 


Opt ion 


Subopt ion 




PM 

SPCLMM 
SYSCON 
SYSLOG 
TND 


PROFILE 




PSEUDO 


One or more pseudo resources. 


QUAN 




RESOURCES 


One or more resources. 


♦S.ACCOUNTING 




SERVICES 


DO 

FPOOLS 
LO 

MAXJOBPRIO 

PDIS 

PO 

TDIS 


SETUP 




STEPACCNT 




TIME 




WSN 





The following steps are required to create o project: 

1. The project is named (i.e.» assigned o logon ID) via the SUPER command CREATE 
PROJECT. 

2. The number of logon accounts are specified (via the project level ACCOUNTS option). 

3. The project authorization record is created (via the project level ADMINISTRATOR 
option). This record establishes the limits of the projects administrator which 
will normally set the limits the project administrator can establish for 
subprojects. 

4. The pockset that will be used for the project's disk storage is defined (via the 
project level PACKSET option). It is essential that the pockset be specified; 
otherwise, the default is #SYS. 

5. The project default record is created (via the project level DEFAULT option). This 
record contains the defaults that will be assigned to users creoted in this project. 

The following figure illustrates how a project is created using the SUPER command CREATE 
PROJECT, SUPER options, and SUPER suboptions. 
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Naffi6S the project* 


rKOJ • Al^UOUN I o«4 


< — 


Specifies the total number of 
logon accounts for this project 
and any subprojects. 


DD/^ 1 ^kAT^LJ AD^CC_1 AAA 

rKOJ ♦MUMAKoc.b^l 






PRO J ♦PRO J tOTo^Z 


< — 


Specifies the number of 
subprojects that may be 
c reot ed . 


PRO U ♦ ADM i N 1 5TRATOR 


< — 


Initiates suboption mode to 
define the project administrator's 






logon user authorization. 


OP 1 ♦not 1 «OotR 




OPT ♦ PASSWORD*! ER C.5A 






OPT ♦PKOr 1 Lt>«VlP/OT 1 


< — 


The PROFILE VIP7801 is supplied 
stondardly with the CP'6 system. 


OPI^SLTUP CM iXLQ StTUP 






OPT ♦StTUP IXEQ MrlLt ,U 






OP I ♦fTSN=RtMOTt 


< — 


REMOTE must have been defined 
as 0 workstot ion. 


OPT^BUDGtT 






CI iD^ T A D/^ c 

SUd^ iCnARGt«YE5 






SUB^MCHARGtS«200 






SUB ♦ dK ACC t SS*"NO 






SUB^ 






/■NOT J. r A /^/^^Vl lAlX 

OPT ♦ FACCOUNT 


< — 


Sets a limit for the project 


OIID^^DAkll TkA_4AAAA 

SUB ♦ GRAN L 1 1^ 1 WW 




administrator's file management 


CI ID^ 

SUB^ 




account . 


A D/> 4 A A A f\tT 4 AAAA D^^^ O 

ABC 100 0 Or 10000 Reaa«?, 


DEFAULT BACKUP, NO ACUP 


OPT^PRIV 






SUB^ASAVt 0,B,G,T 






SUB^DISPJOd 0,d,G 






SUB^ 






/\DT^BDD TV/ 

OPT^PPRIV 






SUB^CNTRi_D 0,B 






SUB^ 






OPT^PStUuO 






SUB^Po CMo,B"6 






Ol ID^ 

SUB^ 






OPT • RESOURCES 






SUB*MT 0*1 tD^Z 






SUB* 






OPT ♦SERVICES 






SUB^MAX TDIS 0»4444 






SUB^ 






OPT* 








<— 


Creotes a project logon user 
default record. 


OPT^PRIV 






SUB^ASAVE 0.B.6 






SUB* 






OPT*PPRIV 






SUB^PIGD 0.8 






SUB* 






OPT*PROFI LE-VIP78ei 






OPT*SETUP 0-MXEQ SETUP* 






OPT*HSET-USER 






OPT* 






PROJ ♦PACKSET-OPfUSER 


< — 


Defines the project packset and 
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0PT»AO3 


packset attributes. 


opT*6R-ieeee 


OPT*SK-ABC? 




OPT»ATTRIBUTES 




SUB»N0LIST-ZZ2? 




SUB* 




OPT* 




PROJ*END 





Note how the various data entry levels are used. The following options can be entered 
at the project level: 



Opt i on 


Descr i pt i on 


ACCOUNTS 


Specifies the maximum number of logon accounts 
that can be authorized in the project. 


ACHARGES 


Specifies the current accumulated charges 
for a project. 


ADMINISTRATOR 


Defines the logon account for the project 
admi ni st rotor. 

INITIATES OPTION MODE (see below). 


DEFAULT 


Defines the default record (for the project users). 
INITIATES OPTION MODE (see below). 


MCHARGES 


Specifies the maximum dollar amount that the 
project can accumulate. 


PACKSET * 


Specifies a packset for the project's file 

management account. INITIATES OPTION MODE (see below). 


PROJECTS 


Specifies whether a project can have subprojects 

by specifying the maximum number of subprojects that can 

be included in the project. 


REMOVE PACKSET 


Removes a packset from a project. 



Three of these options — ADMINISTRATOR, DEFAULT and PACKSET — initiate option mode. 
In online mode, entering any of these project level prompts causes the prompt string to 
change from PROJ* to OPT*. 

Option mode is terminated by entering: 

o one of the options that initiate suboption mode (see below). 

o a blank line in response to the prompt (which returns the user to project level 
option mode). 
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Administrator Option 



ADMINISTRATOR is specified to enable use of the SUPER authorization options to establish 
a unique logon occount for the project administrator. The options that con be specified 
ore listed in the table and are the same as the authorization options described in the 
module "User Authorization". 

Two of these options — BUDGET and FACCOUNT — initiate suboption mode. BUDGET is 
specified in response to the OPT* prompt to enable use of the BUDGET suboptions to 
define project administrator budgetary limits. FACCOUNT is specified in response to the 
OPT* prompt to enable use of PIG processor pockset and account attribute options to 
define project administrator file account attributes. The FACCOUNT option should be 
used at least to set the home packset (via the HSET suboption) for the project. 
Otherwise, the default is #SYS. 

Note that PIG processor commands cannot be entered as FACCOUNT suboptions. Specifying 
FACCOUNT performs an implicit PIG CREATE or MODIFY command. However, using FACCOUNT 
does not make an entry in the Master Account Directory. The PIG processor must be used 
to make that entry. 

Fields in the project administrator's authorization record not explicitly set default to 
the corresponding fields in the DEFAULTP record. 



Default Options 

DEFAULT is specified to enable use of the SUPER authorization options to create a 
default record for users in the project. The default record is set up to simplify the 
user outhor i zot ion task. Most values for users are assigned implicitly from this 
default record. 

Note that the authorization option FACCOUNT and its suboptions are not available through 
the DEFAULT option, and that one of these options — the BUDGET option — initiates 
suboption mode. BUDGET is specified to enable use of the BUDGET suboptions to define 
default record budgetary limits. 



Packset Options 

PACKSET is specified to define the home packset for users in the project and any other 
packsets available to the project. If not specified, the default is |SYS. The PIG 
processor packset and account attribute options are specified as suboptions. Note that 
specifying ATTRIBUTES initiates suboption mode. ATTRIBUTES is specified so that the 
system manager can use PIG processor packset and account attribute options when defining 
the project administrator's packset utilization. 

Neither PIG processor commands nor PIG processor suboptions can be entered as ATTRIBUTES 
suboptions. Specifying ATTRIBUTES performs an implicit PIG CREATE or MODIFY command. 
Only PIG options may be specified. 
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The SUPER coffwnand LIST PROJECT is used to list projects associated with o project 
administrator or the system manager and to list information about a specific project. 
To list projects ossociated with a project administrator or the system manager, the LIST 
PROJECT command is entered as follows: 

CMD»LIST PROJECT 

and a project list similar to the following is listed: 



ABC101 .455LARKIN ABC102.455SMITH 
ABC103,455WELSER 

. . 3 projects I i sted. 



The LIST command: 
CMD*LIST PROJECT DEFAULT 

lists the system authorization default record for users created in a project. 

To list information about a specific project, the LIST PROJECT command is entered as 
fol lows: 

CMD*LIST PROJECT account, name 

A list option is then selected to display the information. The project list options 
are: 



Project List Option 


Informotion Listed 


AC [COUNTS] 


The maximum number of accounts that can be 
created in the project and the number of 
accounts that have been created in the 
project . 


ACH[ARGES] 


The accumulated charges for the project. 


AD[MINISTRATION] 


The project administrator's logon record. 


A[LL] 


The ACCOUNTS, ACHARGES, MCCHARGES. PACKSET 
and PROJECT information. 


OE[FAULT] 


The project default record. 


MC[HARGES] 


The maximum charges that the account may 
accumulote. 
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(cont . ) 


Project List Option 


Information Listed 


PA[CKSET] 


The project pockset information* including 
occount, granule, ond attribute information. 


PR[OJECT] 


The maximum number of subprojects that can be 
created in the project and the number of 
subprojects that have been created in the 
project . 



The following examples illustrate the information that is listed through LIST PROJECT 
options. (The project record listed is the one created in the earlier example.) In 
these examples, note that: 

o All commands to list project information are formatted: 

LIST PROJECT logon-id 

in response to the CMD* prompt. 

o The display to be listed is specified in response to the PROJ* or OPT* prompts, as 
appropriate. That is, the same prompting hierarchy is descended to create, modify 
or list elements of a project. Further, with the exception of the first example 
below, no display will appear until the user enters an END command or RETURN in 
response to a PROJ* prompt. 

The following example uses the ALL option to list the information ovailable through the 
ACCOUNTS. ACHARGES, MCHARGES, PACKSET and PROJECTS options: 
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CMD*L PROJ ABC10e,455WAI 
PROJ»ALL 








ABC100.455WAI 








10 5 




r^UAQ^PQ UAV 

$10000.00 


$4000.00 2 


PROJECTS ACCUM 
0 








PACKSET DPfUSER 








ACCOUNTS MAX ACCOUNTS 
10 5 


ACCUM 


GRANULES MAX 
10000 


GRANULES ACCUM SKELETON 
1000 ABC? 


ATTRIBUTES 
NOLIST-ZZZ? 
1 projects listed. 









These fields are chonged via the following options and suboptions: 



Project Record Field 


Project Level Option 


ACCOUNTS MAX 
ACCOUNTS ACCUM 
CHARGES MAX 
CHARGES ACCUM 

PROJECTS MAX 
PROJECTS ACCUM 
PACKSET 


ACCOUNTS 

Accumulated by system. 
MCHARGES 

Normally, accumulated by the system. 
Can be set by the ACHARGES option. 
PROJECTS 

Accumulated by system. 
PACKSET 


ACCOUNTS MAX 
ACCOUNTS ACCUM 
GRANULES MAX 
GRANULES ACCUM 
SKELETON 


These fields ore all set as OPTION 
level options specified after the 
PACKSET option has been selected. 


ATTRIBUTES 


Initiates suboption mode. See the 
SUPER option and the ADMINISTRATOR 
Options and Suboptions tables. 



The following are examples of using individual options instead of the ALL option to list 
the general project information: 
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CMD*LIST PROJ ABCiee,455WAI 

PRO J ♦AC 

PROJ* 

ABCiee,455WAI 

ACCOUNTS MAX ACCOUNTS ACCUM 
10 5 
. . 1 projects t isted. 

CMD*L PROJ ABCiee.455WAI 
PROJ ♦PA 
PROJ* 
ABC10e,455WAI 

PACKSET DPfUSER 

ACCOUNTS MAX ACCOUNTS ACCUM GRANULES MAX GRANULES ACCUM SKELETON 
10 5 10000 1000 ABC? 

ATTRIBUTES 

NOLIST-ZZZ? 
.. 1 projects listed. 

CMD^L PROJ ABC100.455WAI 

PROJ ♦PR 

PROJ* 

ABC100.455WAI 



PROJECTS MAX PROJECTS ACCUM 
2 0 
. . 1 projects I I sted. 



The following exompie uses the ADMINISTRATION option to list the project odminist rotor's 
logon id record: 



CMD^L PROJ ABC100.455WAI 

PROJ ♦ADMIN 

OPT*ALL 

PROJ* 



ABC100.455IVAI 

PROJECT ADMINISTRATOR 



(cont. next poge) 
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ACHARGES MCHARGES BKACCESS BUDLIM ICHARGE PCHARGE BLINDACCOUNTING 
$3375.97 $5000.00 NO NO YES YES NO 

PROJECT ADMIN HSET NATIVEL PASSWORD PROFILE WSN 

NONE USER YES VIP7801 REMOTE 

OUTPUTPRIO STEPACCNT •S.ACCOUNTING EXPIRE MAX EXPIRE DEF BATNUM 
7 NO NO NEVER NEVER -1 

BANNER1 ALTERABLE BANNER2 ALTERABLE BANNER3 ALTERABLE BANNER4 ALTERABLE 
YES YES YES YES 

BANNERS ALTERABLE BANNERS ALTERABLE BANNER7 ALTERABLE BANNERS ALTERABLE 
YES YES YES YES 

BANNER9 ALTERABLE 
YES 

BANNER1 



BANNER2 



o 
o 
o 



BANNER9 



ALTERABLE SETUP 
6: NO 
G: YES 
0: YES 
T: YES 



SETUP 
B: IXEQ MFILE 

G: 

0: IXEQ SETUP 
T: 



BILLING MEM MAX MEM DEF TIME MAX TIME DEF QUAN PRI06 



B: 


1 


511 


64 


9999 


10 0 


0 


G: 


1 


511 


256 


9999 


9999 0 


0 


0: 


1 


511 


128 


9999 


9999 0 


0 


T: 


1 


511 


256 


9999 


9999 0 


0 



CPROC LAST CPROC MAX LO DEF LO MAX PO 

B: IBEX 99999 1000 99999 

G: IBEX 99999 99999 99999 

0: IBEX 99999 99999 99999 

T: IBEX 99999 99999 99999 





DEF PO 


MAX DO 


DEF DO 


MAX TDIS 


DEF TDIS 


MAX PDIS 


DEF PDIS 


MAX 


B: 


100 


99999 


50 


99999 


2000 


99999 


99999 


31 


G: 


99999 


99999 


99999 


99999 


2000 


99999 


99999 


31 


0: 


99999 


99999 


99999 


4444 


4444 


99999 


99999 


31 


T: 


99999 


99999 


99999 


99999 


2000 


99999 


99999 


31 



(cont. next page) 
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DEF FPOOLS MAX PRIO DEF PRIO 

B: 10 7 7 

G: 10 7 7 

0: 10 7 7 

T: 10 7 7 

ACCESS 
B: YES 
G: NO 
0: YES 
T: NO 
F: NO 

KEY 
NONE 



PRIVILEGES 





ASAVE DISPJOB 


CFEP EXMM EXPM 


FMDIAG 


FHREAD 


FMSEC 


GPP 


lOQ 


lOQW 


B: 


YES 


YES 


NO NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


G: 


YES 


YES 


NO NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


0: 


YES 


YES 


NO NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


T: 


YES 


NO 


NO NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 




JIT 


MAXM MFEP 


MSYS PM SPCLMM SYSCON SYSLOG TND 








B: 


NO 


NO NO 


NO NO 


NO 


NO 


NO 


NO 








G: 


NO 


NO NO 


NO NO 


NO 


NO 


NO 


NO 








0: 


NO 


NO NO 


NO NO 


NO 


NO 


NO 


NO 








T: 


NO 


NO NO 


NO NO 


NO 


NO 


NO 


NO 












PROCESSOR 


PRIVILEGES 


















CNTRLC CNTRLD 


EFT EL NETCON 


LABEL 


PAOMIN 


PIGC PIGD 


RATES REPL 


B: 


NO 


YES 


NO NO NO 




NO 


YES 


NO 


NO 


NO 


NO 


G: 


NO 


NO 


NO NO NO 




NO 


YES 


NO 


NO 


NO 


NO 


0: 


NO 


YES 


NO NO NO 




NO 


YES 


NO 


NO 


NO 


NO 


T: 


NO 


NO 


NO NO NO 




NO 


NO 


NO 


NO 


NO 


NO 




SPIDERC SPIDERD 


SUPER SUPERA 


SUPERD 


SUPERF 


SUPERW 


VOLINIT SYSCON 


B: 


NO 


NO 


NO NO 




NO 


NO 


NO 


NO 




NO 


G: 


NO 


NO 


NO NO 




NO 


NO 


NO 


NO 




NO 


0: 


NO 


NO 


NO NO 




NO 


NO 


NO 


NO 




NO 


T: 


NO 


NO 


NO NO 




NO 


NO 


NO 


NO 




NO 



PIGETTE 
6: NO 
G: NO 
0: NO 
T: NO 



RESOURCES 

MT OP 

B: 6 4 

G: 4 4 

0: 6 4 

T: 4 4 
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FACCOUNT 

ACCOUNT IGRANULES USED ReodDe I recWnewUpdateScratchNoM stFi tmodExecCreote 
ABCiee 75 of leeee Read-?.Nol ist«ZZZ? 

FE-MFPRG FE-MAX-ACCT-MEM FE-DBACCN 
0 9999 

FE-MINTS FE-MAX-TIME FEHylAX-MEM FE-BILLING 



U: 


0 


9999 


128 


1 


C: 


0 


9999 


128 


1 


H: 


0 


9999 


128 


1 


G: 


0 


9999 


128 


1 



FE-PRI VI LEGES 



EXMM EXPM FMREAD FMSEC GPP MAXM MSYS SPCLMM SYSLCX^ TND INTCON 



U: 


NO NO NO NO 


NO 


NO NO 


NO 


NO 




NO 


NO 


C: 


NO NO NO NO 


NO 


NO NO 


NO 


NO 




NO 


NO 


H: 


NO NO NO NO 


NO 


NO NO 


NO 


NO 




NO 


NO 


G: 


NO NO NO NO 


NO 


NO NO 


NO 


NO 




NO 


NO 




CQ SNAP SCREECH 
















U: 


NO NO 


NO 
















C: 


NO NO 


NO 
















H: 


NO NO 


NO 
















6: 


NO NO 


NO 


















FE PROCESSOR PRIVILEGES 
















CNTRLC CNTRLD EFT EL 


NETCON 


LABEL 


PADMIN 


PIGC 


PIGD 


RATES REPLAY 


U: 


NO 


NO NO NO 


NO 


NO 


YES 


NO 


NO 


NO 


NO 


C: 


NO 


NO NO NO 


NO 


NO 


YES 


NO 


NO 


NO 


NO 


H: 


NO 


NO NO NO 


NO 


NO 


YES 


NO 


NO 


NO 


NO 


G: 


NO 


NO NO NO 


NO 


NO 


YES 


NO 


NO 


NO 


NO 




SPIDERC 


SPIDERD SUPER 


SUPERA 


SUPERD SUPERF 


SUPERS 


VOLINIT 


SYSCON 


U: 


NO 


NO NO 


NO 


NO 


NO 


NO 


NO 




NO 


C: 


NO 


NO NO 


NO 


NO 


NO 


NO 


NO 




NO 


H: 


NO 


NO NO 


NO 


NO 


NO 


NO 


NO 




NO 


G: 


NO 


NO NO 


NO 


NO 


NO 


NO 


NO 




NO 



PIGETTE 
U: NO 
C: NO 
H: NO 
G: NO 



1 projects listed. 



Note thot: 
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o the project administrator's logon id record contains the exact same fields as any 
user authorization record. These fields are broken down by class in module 4-1 and 
some of them are described in module 4-3. They are all described In detail in the 
CP-6 Systems Support Reference Manual (CE41). 

o because the project list option ALL was specified, the complete authorization record 
for the project administrator has been listed. 

Several fields can be selected for listing by entering the names of the fields prior to 
entering a null line or *END'. For example: 



CMD«LIST PROJ ABCiee.455WAI 

PROJ*ADMIN 

OPT'iHSET; SETUP 

OPT* 
PROJ» 


< — Multiple options must be 

sepo rated with a semi -co Ion. 


ABCiee.455WAI 




PROJECT ADMINISTRATOR 




HSET 
USER 




SETUP 
B: IXEQ MFILE 

G: 

0: IXEQ SETUP 
T: 




. . 1 projects 1 i sted. 





Options specified must come from the some group. That is, the ALL options 
( ACCOUNTS. ACHARGES. MCHARGES. PACKSET and PROJECTS con be specified together, any 
combination of ADMINISTRATION options can be specified together, ond ony combinotion of 
DEFAULT options can be specified together. For example: 
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CMD^LIST PROJ ABC100,455WAI 
PROJ*ACH;MCH;PRO 
PROJ* 
ABC100,455WAI 

CHARGES MAX CHARGES ACCUM PROJECTS MAX PROJECTS ACCUM 
$10,000.00 $4000.00 2 0 

. . 1 projects I Isted. 

CMD*L PROJ ABC100,455WAI 

PROJ ♦DEFAULT 

OPT*PRIV;PPRIV 

OPT* 

PROJ* 

ABC100.455WAI 

DEFAULT RECORD FOR PROJECT 



PRIVILEGES 





ASAVE D ISP JOB CFEP EXMM EXPM 


FMDIAG 


FMREAD 


FMSEC GPP 100 


KXIH 


B: 


NO 


NO 


NO NO NO 


NO 


NO 


NO NO NO 


NO 


G: 


NO 


NO 


NO NO NO 


NO 


NO 


NO NO NO 


NO 


0: 


NO 


NO 


NO NO NO 


NO 


NO 


NO NO NO 


NO 


T: 


NO 


NO 


NO NO NO 


NO 


NO 


NO NO NO 


NO 




JIT 


MAXM 


MFEP MSYS PM 


SPCLMM 


SYSCON 


SYSLOG TND 




B: 


NO 


NO 


NO NO NO 


NO 


NO 


NO NO 




G: 


NO 


NO 


NO NO NO 


NO 


NO 


NO NO 




0: 


NO 


NO 


NO NO NO 


NO 


NO 


NO NO 




T: 


NO 


NO 


NO NO NO 


NO 


NO 


NO NO 








PROCESSOR PRIVILEGES 












CNTRLC CNTRLD EFT EL NETCON 


LABEL 


PADMIN PIGC PIGD RATES REPLAY 


B: 


NO 


NO 


NO NO NO 


NO 


YES 


NO NO NO 


NO 


G: 


NO 


NO 


NO NO NO 


NO 


YES 


NO NO NO 


NO 


0: 


NO 


NO 


NO NO NO 


NO 


YES 


NO NO NO 


NO 


T: 


NO 


NO 


NO NO NO 


NO 


YES 


NO NO NO 


NO 



SPIDERC SPIDERD SUPER SUPERA SUPERD SUPERF SUPERW VOLINIT SYSCON 



B: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


G: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


0: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


T: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 



PIGETTE 
B: NO 
G: NO 
0: NO 
T: NO 

. . 1 projects t i sted. 
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However, the following command mixes project display groups and will not be honored: 



CMD^LIST PROJ ABCie0.455WAI 
PROJ * ACHARGES ; ASAVE ; MCHARGES 

The specification: 

CMD*L PROJ ABC100.455SMITH 

PROJ ♦DEFAULT 

OPT*ALL 

results in listing of the project default record. The project default record is an 
authorization record: it has the same fields as the default record (listed in module 
4-1) and the project administrator's logon id record (listed above). The project 
default record contains the defaults that will be used for users defined within the 
project . 



Administering Projects 

SUPER features a number of commands that support the project authorization process. 
Assume the following system manager, project, and user hierarchy hos been defined: 



ABceee.455WAi 



<— 



System manager logon id. 



ABC1M.455MARTNER 



< — 



Project administrator logon 
account id for this project. 



ABC101,455HIRSCH 

A8Cie2.455GIBS0N 
ABCie3.455QUICK 



Three users created in this 
project . 



ABC2e0.455FOSNIGHT 



< — 



Project administrator logon 
account id for this project. 
Two users creoted in this 
project . 



AeC201 .455M0SSM0ND 
ABC2e2,455HILL 



< — 



ABC30e.455SOCOL 



< — 



Project administrator logon 
account id for this project. 
One user created in this 
project • 



ABC3ei,455KLEIN 



<— 
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The MAKEME coiMiand is used to move from project to project (and from project to system 
manoger) within the hierarchy as follows: 

o MAKEME project_logon.account.id Is used to move through the project hierarchy. 

o MAKEME RESET Is used to move from anywhere in the hierorchy to the system monager 
level of the hierarchy. (This capability is not normally made available to project 
administrators. ) 

The SUPER processor responds to a number of commands thot enable manlpulotlon of the 
projects and users defined in a project hierarchy by allowing already defined projects 
and users to be moved within the hierarchy as follows: 

o the TIE command attaches a logon user to a project; the TIE PROJECT command attaches 
a project as a subproject. 

o the UNTIE command and UNTIE PROJECT command detach a user in a project and project 
in the hierarchy (respectively). 

Note that in all these coses: 

o all projects and users identified in these commands must already exist. 

o the operation can only be performed at a lower level in the hierorchy than the 
current level. Thus: 



ABC300 . 455S0C0L cannot use any of the commands described above. 

ABC200»455FOSNIGHT can use the MAKEME command to become ABC300. 
455S0C0L and to return to ABC200,455FOSNIGHT. and can use the 
TIE and MODIFY command only with the subordinate project (ABC300, 
455S0C0L) . 

ABC100,455MARTNER can use the MAKEME command to become either of 
the subordinate projects (ABC200.455FOSNIGHT or ABC300 .455S0C0L) . 
and con use the TIE and MODIFY commands with either of the subordinate 
projects, and so on. 

The MODIFY command con also be used to turn o user into a project and a project into a 
user. In this case» too, the restrictions just described apply. 

The MODIFY PROJECT command is used to modify the project administrator or project 
default record, and the REMOVE PROJECT command is used to remove a project. 

The following example Illustrates use of some of these commands. 



1 SUPER 


< — The SUPER processor is invoked. 


CP-6 SUPER C00 




CMD*LIST PRO J 


<— The LIST PROJECT command with 


PRO J* 


no further specification is 




issued to list all projects (at 




the system manager level) or sub- 




projects to the current project. 


ABC100.455MARTNER 


ABC200 , 455F0SN I GHT ABC300 , SOCOL 
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. .3 projects I i sted. 

CMD*MAKEME ABCiee.455MARTNeR <— The MAKEME cofwnand is issued to 

access the first level project. 
Project: ABC1 00 • 455MARTNER < — A verification message listing 

the project logon id is 
displayed. 

CMO*LIST < — The LIST command with no further 
OPT* specification is issued to list 

all user logon ids in the 

project . 

ABC101 .455HIRSCH ABC102,455GIBSON ABC103.455QUICK 

. .3 users i isted. 



CMD*MAKEME ABC200.455FOSNIGHT 

Project: ABC200.455FOSNIGHT 

CMD*LIST 
OPT* 



< — The MAKEME command is issued to 
access the second level project 



< — The LIST command with no further 
specification is issued to list 
alt user logon ids in the 
project. Note that users in a 
project can only be listed after 
the owning project logon id has 
been established as the current 
project . 



ABC201 , 455M0SSM0N0 ABC2e2 , 455HI LL 



. .2 users I i sted. 



CMD*TIE ABC201.455MOSSMOND TO ABC1 00 . 455MARTNER 

The TIE command is used to move 
a user from project A6C200, 
455F0SNIGHT to project ABC100. 
455MARTNER. Note that, in this 
case, a USER is moved to a 
PROJECT. The following messages 
are produced to indicote the move 
is successful : 

.. User "ABC201 .455MOSSM0ND" untied from project "ABC200.455rOSNIGHT" . 
User "ABC201 ,455M0SSM0ND" tied to project "ABC100.455MARTNER" . 

CMD»M0DIFY ABC202.455HILL TO PROJ <— The MODIFY command is used to 

change o user to a project logon 
id. The following messages 
confirm the change: 

..User "ABC202,455HILL" untied from project "ABC200,455FOSNIGHT" . 

..User "ABC202.455HILL" modified to project "ABC202.455HILL*' . 

CMD*REMOVE PROJ ABC200,455FOSNIGHT <— The REMOVE PROJECT command is 

used to remove a project from the 
project hierarchy. The following 
messages confirm the deletion, 
indicating that no users hove 
been deleted since all users In 
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the project hove already been 




moved : 


Project "ABC200.455FOSNIGHT" 


removed. 0 users removed. 


.. 1 projects removed. 




CMD^END 




NO Errors 


< — A count of errors and warning 


NO Warnings ♦♦• 


messages terminates the SUPER 




session. Note that if on error 




occurs or warning diagnostic is 




issued, the message is listed 




at the time the command, option 




or suboption is processed. 



Notes on Using SUPER 

The following notes will alert the project administrator to some features of SUPER that 
might not be immediately apparent or that need special emphasis: 

1. When creating a project: 

o Always create the project authorization record before the project default record 
or project pockset association is established. 

o To enable file account management to function correctly, always declare the home 
pockset (HSET) for the project administrator and for the default record. The 
home pockset will normally be the some for both, and will normally be the some 
OS the pockset declared via the PACKSET option. 

o To enable pockset management, always use the PACKSET option to establish the 
pockset association. 

o The system default for the SUPER PRIVILEGE ASAVE, which enables users to 

reconnect to a saved image following a terminal disconnect, is NO. Frequently, 
the ASAVE privilege wi I i be set to YES for users. The project administrator may 
wish to simplify assignment of a YES value to the ASAVE field in a user record 
by changing the field value from NO to YES in the project default record. 

o Be aware that using the FACCOUNT option will invoke the PIG processor to Create 
or Modify a file management account; it wilt not automatically moke on entry in 
the Master Account Directory. Subsequent to creating project accounts, the 
person creating the accounts will wont to be sure to invoke the PIG processor to 
enter the accounts in the Master Account Directory. 

2. For project authorization, the abbreviation PA can be specified in response to the 
prompts PROJ* or SUB*, and means different things. At the option level, in response 
to the prompt PROJ*. PA stands for PACKSET. However, when the ADMINISTRATOR or 
DEFAULT options hove been specified, PA is the abbreviation for PASSWORD and is 
entered in response to the prompt SUB*. For user authorization, PA is always 
entered at the option level, in response to the prompt OPT*, and is always the 
abbreviation for PASSWORD. 
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3. For project authorization, values for accounting control fields are entered at the 
option level (via the ACHARGES and MCHARGES option). For user authorization, values 
for accounting control fields ore entered at the suboption level (first the BUDGET 
option is specified, and then the suboptions ACHARGES and MCHARGES, as wet! as 
others, may be specified). 

4. The PACKSET suboption SKELETON is used to establish account naming conventions. The 
SKELETON suboption imposes a formatting requirement on the account creator. For 
example: 

PACKSET-DPfUSER 

GRANULES«50e 

SKELETON-ABC? 

establishes the packset USER as the project packset, establishes its size as 500 
granules ond establishes that the names of all accounts must begin with ABC. 
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User Authorization 



A user may be: 

o A humon being at a timesharing (online) terminal, 
o A series of commands running in the batch stream, 
o Special processes called ghosts. 

o Transaction Processing Users (TPUs) running as part of a TP instance. 

o Front-end programs (FPRGs) and hondlers running in Front-End Processors (FEPs). 

Note that in the CP-6 system these users are distinguished by the way they are defined 
in SUPER. 

In SUPER, these different types of users are seen as different modes. Therefore, the 
process of authorizing a user is the same regardless of the type of user. The process 
of authorizing these users is the same, also, regardless of whether or not a project 
hierarchy is used. 

Authorization Elements 

The precise steps to authorize a user via SUPER will vary according to the policies at a 
given installation. However, regardless of any installation specific requirements, the 
following steps must be considered when authorizing a user: 

o Give the user a user logon ID that wilt identify the user to the system. 

o Establish budget limits for the user. 

o Establish the system resources available to the user. 

o Define the user's service limits. 

o Define the user's physical resource limits. 

o If appropriate, define the number of pseudo resources that may be authorized by the 
user. 

o Set up an environment tailored to the specific user. 

o Identify the file management packset that will contain the user's files. (The file 
management account (s) are created by entering PIG via the SUPER option FACCOUNT.) 
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EstabKshing Budget Limits 



Basically, each user is given a dollar budget and then charged for everything that is 
done. When the last of the budget is used, the user may be denied access to the system. 
There are two steps in the process: 

1. The rote schedule established through the RATES processor (see Module 10) is 
assigned to the user with the SUPER option BILLING. 

2. A budget is established for the user by setting a maximum volue on the charges the 
user may accumulate. The SUPER option BUDGET and its suboptions ore used to 
indicate whether or not the user is to be denied access to the system if the budget 
is exhausted, and whether or not the user is to be linked (for budget purposes) to 
another logon id. In addition, the user's accumulated charges may be modified via 
the BUDGET option, the BUDLIM option con be used to indicate that the user is to be 
charged at the end of every job step instead of at the end of a job. A list of 
charges for system resources is established by the RATES processor (see Module 10). 



Establishing System Resource Limits and Def auKs 

The scope of each user's demand on the finite set of system resources must be limited. 
There are two basic ways of setting limitations: the first is to limit access to the 
resource itself; the second is to assign dollar values to the resources and limit the 
budget (in dollars) available to the user. A combination of the two methods is usually 
used. 

The SUPER option MEMORY is used to establish maximum and default memory values. That 
is, the MEMORY option is used to limit the size of each user's memory and assign a 
default memory ot location when logging on to the system. 

The SUPER option TIME is used to establish maximum and default limits for time for batch 
jobs only (measured in CPU time, not in wall-clock time). 



Defining Service Limits and Defaults 

Service limits include such things as line printer paper, punched cords, and temporary 
disk space. These limits apply on o per job basis; there is no global maximum covering 
multiple jobs submitted by the user. The SUPER option SERVICES and its suboptions 
establish the maximum and default values for these items. 



Defining Physical Resource Limits 

Physical resource limits define the largest request that will be honored for a user for 
physical devices (such as topes, disk pocks, and line printers). The SUPER option 
RESOURCE and its suboptions ore used to define these limits. The limits established for 
physical resources define the largest request that will be honored for the user. The 
limits set here ore for resources defined at boot-time (through the TIGR check^ or 
through the SUPER processor DEFINE DEVICE command (for FEP-connected resources). 
Physical resources must be specifically requested by the user (via the IBEX command 
{RESOURCE (in botch mode) or lORES (in online mode)). 
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Definhg Pseudo Resources 



Up to eight pseudo resources can be authorized for a user. The SUPER option PSEUDO and 
its suboptions establish the maximum number of the named pseudo resources the user may 
acquire. As with physical resources, defaults are not permitted. 



Taioring the Environment to the User 

This step is more of a convenience to the user than a restriction of access to the CP-6 
system. Some of the more commonly used options available to set up an environment 
tailored to the specific user include: 

o PROFILE* which establishes the name of the default terminol profile to be used when 
this user logs on a timesharing terminal. 

o WSN, which establishes the nome of the default destination of printed output. 

o PRIVILEGE, which enables selected users to access CP-6 capabilities not intended or 
necessary for most users. The privileges are ASAVE. CFEP, DISPJOB. EXMM, EXPM. 
FMDIAG. FMREAD, FMSEC. GPP. lOQ. lOOH, JIT. MAXM. MFEP, MSYS. PM. SPCLMM. SYSCON. 
SYSLOG. and TND. They are all described in the CP-6 System Support Reference Manual 
(CE41) in the Section "SUPER: System Administration".) 

o PPRIVILEGE. which enables a user to have access to processors that should not 
normally be available to the general user of the system. (These processors ore 
ANLZ. CONTROL. EFT. ELAN. LABEL, NETCON, PIG, PIGETTE, SPIDER, SUPER, VOLINIT, RATES 
and REPLAY.) 

o CPROC. which permits the spec i f i cot i on of a command program to be associated with 
the user when the user logs on (the default is IBEX). 

o SETUP, used with CPROC. to define a single command or command file to be executed by 
the associated command program immediately after logging on. The command(s) defined 
via SETUP will be the first one(s) executed every time the user logs on. 

o LAST CPROC, which permits the specification of a command program to be associated 
with the user when the user logs off. 

In most coses, the system manager or project administrator will consider and set up 
these limitations and capabilities only once. The decisions mode ore stored in a 
default record (described below) which is used to assign most values to newly authorized 
users. 



User Authorization Record 

For each user, a user authorization record is created thot contains the authorization 
information. Every user authorization record contains the same fields for establishing 
these characteristics of the user. 

Each authorization record consists of over 140 fields of information. Each field is 
assigned a name and o value. When a user authorization record is listed, the field name 
appears above the field value. For example: 

ACHARGES < — Field name 
$e.eo < — Field value 

Many of these fields (especially those fields associated with privileges and budgetary 
limits) take YES or NO values that determine whether a user has or does not have the 
authority to use a system capability. For example: 
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ACHARGES MCHARGES 


BKACCESS 


BUDLIM 


ICHARGE 


PCHARGE 


BLINDACCOUNTING 


$3617.22 NONE 


YES 


NO 


YES 


YES 


NO 



Other fields (especially those fields associated with service and resource Mniits) take 
decimal values. For example: 





BILLING 


MEM MAX 


MEM DEF TIME MAX 


TIME DEF 


QUAN 


PRI06 




B 


1 


511 


64 9999 


ie 


0 


e 




G 


1 


511 


256 9999 


9999 


0 


e 




0 


1 


511 


128 9999 


9999 


e 


e 




T 


1 


511 


256 9999 


9999 


0 


0 






CPROC 




LAST CPROC 




MAX LO 


DEF LO 


MAX PO 


B 


IBEX 








99999 


1000 


99999 


G 


IBEX 








99999 


99999 


99999 


0 


IBEX 








99999 


99999 


99999 


T 


IBEX 








99999 


99999 


99999 



Note that: 

o All authorization fields are present in the record even if the value is null (see 
LAST CPROC above). 

o \Where appropriate, the fields ore divided into modes: B(atch) , G(ho8t), O(nline) 
and T(P). 

o Where appropriate, the fields take text values other than YES or NO (e.g., CPROC, 
above) . 

The following figure is a listing of o user authorization record. 



72 



User Authorization Record 
Module 4*3 



cE6e-ee 



ACHARGES MCHAR6ES BKACCESS BUDLIM ICHARGE PCHARGE BLINDACCOUNTING 
$3617.00 NONE YES NO YES YES NO 

These fields are set and chonged via the BUDGET authorization 
subopt ions. 

PROJECT AOMIN HSET NATIVEL PASS^WORD PROFILE WSN 

LNHOO1.100101 USER YES VIP7205 LOCAL 

OUTPUTPRIO STEPACCNT ♦S.ACCOUNTING EXPIRE I^X EXPIRE DEf BATNUM 
7 NO NO NEVER NEVER -1 

PROJECT ADMIN is set when the user authorization record is 
created. It can be changed via the SUPER command MODIFY 
PROJECT. The other fields are set and changed using SUPER options 
that are the same as the field names except for EXPIRE MAX 
and EXPIRE DEF both of which ore set and changed through the 
EXPIRE option. 

BANNER1 ALTERABLE BANNER2 ALTERABLE BANNER3 ALTERABLE BANNER4 ALTERABLE 
YES YES YES YES 

BANNERS ALTERABLE BANNERS ALTERABLE BANNER7 ALTERABLE BANNERS ALTERABLE 
YES YES YES YES 

BANNER9 ALTERABLE 
YES These record fields describe the nine user 

fields on print out banners: whether those 
BANNER1 fields can be altered and the text they 

cental n. 

BANNER2 
o 
o 
o 

BANNER9 

These fields are set and changed through the SUPER option 
BANNERTEXTn. 

ALTERABLE SETUP 

B: YES These fields define the command processor 

G: YES commonds that ore to be executed at logon. 

0: YES 
T; YES 



SETUP 

B 

G 
0 



IXEQ BFILE 
IXEQ $SETUP 



These fields ore set and chonged through the SUPER option 
SETUP. 
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BILLING MEM MAX MEM DEF TIME MAX TIME DEF QUAN PRIOB 



B: 


1 


511 


64 


9999 


10 


0 


0 


G: 


1 


511 


256 


9999 


9999 


0 


0 


0: 


1 


511 


128 


9999 


9999 


0 


0 


T: 


1 


511 


256 


9999 


9999 


0 


0 



CP90C LAST CPROC 

B: IBEX 
G: IBEX 
0: IBEX 
T: IBEX 



These fields define additional environment ond resource 
attributes. They are set and changed using SUPER options that 
ore the same as the field names except for MEM MAX and MEM DEF 
which are both changed through the MEMORY option, and TIME MAX 
and TIME DEF which are both changed through the TIME option. 



These fields contain service limits. 



MAX LO DEF LO MAX PO 

99999 1000 99999 

99999 99999 99999 

99999 99999 99999 

99999 99999 99999 





DEF PO 


MAX DO 


DEF DO 


MAX TDIS 


DEF TDIS 


MAX PDIS 


DEF PDIS 


MAX 


B: 


100 


99999 


50 


99999 


2000 


99999 


99999 


31 


G- 


99999 


99999 


99999 


99999 


2000 


99999 


99999 


31 


0: 


99999 


99999 


99999 


99999 


9999 


99999 


99999 


31 


T: 


99999 


99999 


99999 


99999 


2000 


99999 


99999 


31 



DEF FPOOLS MAX PRIO DEF PRIO 
B: 10 7 7 
G: 10 7 7 
O: 10 7 7 
T: 10 7 7 



The values in these fields ore set and chonged via suboptions 
specified after the SUPER option SERVICES has been specified. 



ACCESS 
B: YES 
G: NO 
0: YES 
T: NO 
F: NO 



KEY 
NONE 



These fields contain additional environment fields. The values 
in each of these fields can be set and changed via the SUPER 
options ACCESS and KEY. respectively. 



PRIVILEGES 



ASAVE 


D ISP JOB 


CFEP 


EXIyM 


EXPM 


FMDIAG 


FMREAD 


FMSEC 


GPP 


lOQ 


lOQW 


B: YES 


YES 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


G: YES 


YES 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


0: YES 


YES 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


T: YES 


YES 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 
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JIT 


MAXM 


MFEP 


MSYS 


PM 


SPCLMM 


SYSCON 


SYS LOG 


TND 


B: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


G: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


0: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


T: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 



These fields contain the user's privileges. The values in 
these fields are set and changed via suboptions specified 
after the SUPER option PRIVILEGES has been specified. 



PROCESSOR PRIVILEGES 



CNTRLC 


CNTRLD 


EFT 


EL 


NETCON 


LABEL 


P ADM IN 


PIGC 


PIGD 


RATES 


REPl 


B: NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


G: NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


0: NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


T: NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 





SPIDERC 


SPIDERD 


SUPER 


SUPERA 


SUPERD 


SUPERF 


SUPERW 


VOLINIT 


SYSCON 


B 


NO 


NO 


NO 


NO 


NO 


YES 


YES 


NO 


NO 


G 


NO 


NO 


NO 


NO 


NO 


YES 


YES 


NO 


NO 


0 


NO 


NO 


NO 


NO 


NO 


YES 


YES 


NO 


NO 


T 


NO 


NO 


NO 


NO 


NO 


YES 


YES 


NO 


NO 



PIGETTE 
B: NO 
G: NO 
0: NO 
T; NO 



These fields contain the user's processor privileges. The 
values in these fields are set and changed via suboptions 
specified after the SUPER option PPRIVILEGES has been 
speci f ied. 



PSEUDO RESOURCES 



P6 


STAR 


B: 1 


1 


G: e 


e 


0: 1 


e 


T: 16416 


0 



These fields contain the user's pseudo resources. The values 
in these fields are set and changed via suboptions specified 
after the SUPER option PSEUDO has been specified. 



RESOURCES 





MT 


DP 


LP 


CP 


7T 


B: 


4 


4 


0 


0 


0 


G: 


4 


4 


0 


0 


0 


0: 


4 


4 


0 


0 


0 



These fields contain the set of 
allocatoble system resources for 
this user. 
16416 16416 16416 16416 0 



The values in these fields are set and changed via suboptions 
specified after the SUPER option RESOURCES has been specified. 

FACCOUNT 

ACCOUNT IGRANULES USED ReadDei recWnewUpdoteScratchNol I stFi tmodExecCrea 
ABC003 393 of 2000 Read-?, DEFAULT BACKUP, CGMEM-40, Nolist-Z? 
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These fields contain the user's file monagement account infor- 
mation. File management account information is assigned and 
maintained via the CP-6 PIG processor. PIG can be accessed 
through the SUPER option FACCOUNT so that matching logon account 
and file management account information can be processed os part 
of the same activity. However, the PIG processor must still 
be entered to make the appropriate entry in the Moster Account 
Oi rectory . 



FE-MFPRG 

e 



FE-MAX-ACCT-44EM 
9999 



FE-DBACCN 



FE-MINTS FE-MAX-TIME FE-44AX-MEM FE-BILLING 



U: e 
C: e 
H: e 
G: 0 



9999 
9999 
9999 
9999 



128 
128 
128 
128 



FE-PRI VI LEGES 



EXMM 


EXPM 


FMREAD 


FMSEC 


GPP 


MAXM 


MSYS 


SPCUyN 


SYSLOG 


TND 


INK 


U: NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


C: NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


H: NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


G: NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 



CQ SNAP SCREECH 

U: NO NO NO 

C: NO NO NO 

H: NO NO NO 

G: NO NO NO 

FE PROCESSOR PRIVILEGES 

CNTRLC CNTRLD EFT EL NETCON LABEL PADMIN PIGC PIGD RATES REPLAY 

U:NO NO NONONO NONO NONONO NO 

C:NO NO NONONO NONO NONONO NO 

H:NO NO NONONO NONO NONONO NO 

G:NO NO NONONO HO HO NONONO NO 

SPIDERC SPIDERD SUPER SUPERA SUPERD SUPERF SUPERWI VOLINIT SYSCON 



U: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


C: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


H: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


G: 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 


NO 



PIGETTE 
U: NO 
C: NO 
H: NO 
G: NO 



These fields contain FEP resource, privilege and processor priv- 
ilege information. Note that of the three settable FEP 
options — FEP resource, privilege and processor privilege 
options — only FEP resource and privilege options should be 
set. The third category. FEP processor privilege can be 
set in SUPER, but FEP processor privileges are not currently 
supported in the system. The FEP modes are: U(ser), C(omgroup). 
H(andler) and G(host}. The values in these fields ore set and 
changed via the oppropriate SUPER FEP options and suboptions. 



(cont . next page) 
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Default Record 



The values in alt fields can be assigned and changed via SUPER options (described 
below). In fact, the process of authorization is usually fairly simple because a 
default record is used to assign values for most of the fields in the user authorization 
record. When a user authorization record is created, a field not explicitly assigned a 
value via a SUPER option is implicitly assigned the value from the corresponding field 
in the default record. 

If a project has been created, the project default record (DEFAULTP) will be used to 
make implicit value assignments to the fields in the user outhor i zat i on record. The 
project default record is created by the project (or system) manager when the project is 
created (see Module 4-2). If a project hierarchy is not being used, the system default 
record will be used for such assignments. The system default record (named DEFAULT) is 
supplied with the system and can be modified by the system manager. (Module 4-1 contains 
a listing of the system default record. 



Creating User Authorizations 

Once SUPER has been invoked, creation of a user authorization is initiated by entering 
the following SUPER command: 

CREATE account, name 

This command: 

o assigns the user logon id, 

o initiates user authorization mode. 



User Logon D 

The user logon ID identifies the user to the system. The logon ID is the key to gaining 
access to the CP— 6 system. As such, the logon id is the system manager and project 
administrator's primary means of control over the users of the system. The facilities 
of a CP-6 system may not be used without a valid logon ID. As described in module 1-1, 
the user logon ID consists of: 

occount , name , password 

The account defines the user's default file management account and determines a user's 
access to the files of other users. The account value consists of up to 8 alphanumeric 
characters. The name identifies the individual user. The name value consists of 1-12 
alphanumeric characters and the symbols $ and :. These two fields are assigned via the 
SUPER command CREATE. The password is the user's tool for controlling access. An 
initial password can be assigned by using the SUPER option PASSVVORD when defining the 
user. 

The values assigned to these logon ID fields will result from a careful pre-l nsta I I at t on 
planning of account groupings, of name conventions, and of policy regarding assignment 
of an initial password. Module 1-1 emphasizes the importance of accounts as the 
cornerstone of CP-6 security and file management procedures, and why grouping of users 
by account is important. Module 1-1 Includes some examples of different grouping 
schemes. 
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Initiating User Authorization Mode 



The SUPER coinmand CREATE initiates user authorization mode. Before this command is 
issued, the project or system manager will have determined which fields in the user 
authorization record are to be explicitly assigned values and which fields are to 
default to the corresponding field values in the default record. 

The online prompt to enter user authorization options is OPT*. Some options Introduce o 
suboption mode. The online prompt to enter suboptions is SUB*. Note that in user 
authorization there are three levels of data entry and three prompts: 

Data Entry Level Prompt 

The SUPER command level CMD* 

The option level OPT* 

The suboption level SUB* 

The following table lists the user authorization options and suboptions. Note that: 

o most of the options parallel field names in the user outhor i zat ion 
record . 

o many options can be specified: 

f i e I d_name«YES 
or 

f i e I d_name-NO 

In these coses, specifying just 
f i e I d_name 

is the some as specifying f i e 1 d.name»YES . 

o the BUDGET. FACCOUNT, FEPPRIVILEGE. FEPRIVILEGE, FEPSEUDO. 

FEPRESOURCES, PPRIVILEGE. PRIVILEGE PSEUOO, RESOURCES end SERVICES 
options introduce suboption mode. 

o in general, keywords con be shortened by entering only the first 
few characters of the keyword. In this module, the minimum 
portion of a keyword appears outside square brackets, while 
the characters that are not required, that is, the extended 
portion of the keyword, are printed inside square brackets. 
The SUPER user must enter the minimum portion, and may choose 
to enter more. The reader should be aware that: 

- all of the minimum portion of a keyword must be entered 
and must be entered exactly as shown. 

- any number of characters in the extended portion may be 
added, but they must be entered in sequence. 

Looking at the option: 

FA[CCOUNT] 
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The SUPER user can enter: 


The SUPER user CANNOT enter: 


FA 


F 


FAC 


FAT 


FACC 


FANT 


FACCO 


FCCOUNT 


FACCOU 


FACOUNT 


FACCOUN 


FACCXYZ 


FACCOUNT 






and so on. 





Table 


5. User Authorization Options and Subopt ions 


Opt ions 


Subopt ions 


Comnien t 


AC[CESS] 








BANNERTEXT 








BA[TNUM] 






The BATNUM option can 
be specified in SUPER 
but is currently not 
supported in the system. 


BI[LLING] 








BU[D6ET] 


AC 
BK 
BL 
BU 
IC 
MC 
PC 


HARGESl 
ACCESS] 

INDACCOUNTING] 

DLIM] 

HARGE] 

HARGES] 

HARGE] 




CP[ROC] 








EX[PIRE] 








FA[CCOUNT] 


AfCUP] or NOA[CUP] 
B[ACKUP] or NOB[ACKUP] 
CG[MEIyi] 
C[HECKWRITE] 

or NOC[HECKWRITE] 
D[ATACHECKVVRITE] 

or NOOFATACHECKWRITE] 
OrEFAULTjB[ACKUP] 
G 'RANLIMJ 
M[ERGEACCESS] 

or NOM[ERGEACCESS] 
N[EWFDS] or NON[EWFDS] 
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Table 5. User Authorization Options and Subopt ions (cont.) 



Opt ions 



Subopt ions 



Comment 



FEBI[LLING] 

FEDB[ACCN] 

FEMA[CCTMEM] 

FEMF[PRG] 

FEMI[NTS] 

FEMME[MORY] 

FEMTI[ME] 

FEPP[RIVILEGE] 



SH[ELFTIME] or NOSH[ELFTIME] 
0[WNER] 

PRfOTECTED) or NOT PR[OTECTED] 
PUIRGE] or NOPU[RGE] 
SJ{Cm] or NOST[ail] 

File Access Subopt ions: 
D[ELR] 
DELFIILE] 
ErXECUTE] 
FIITMODE] 
N[OLIST) 
READ or RD 
REATTR 
SCRATCH 
UrPDATE] 

\m[new] 

WR[ITE] 

Account Access Subopt ions: 
C[REATEl 
NO[NE] 



CNTRLC 
CNTRLD 
EF[T] 
EL 

LA[BEL] 

NETCON 

PADMIN 

PIGC 

PIGD 

PIGETTE 

RATES 

REPLAY 

SPIDERC 

SPIDERD 

SU[PERl 

SUPERA[UTH] 



NOTE: The FEPPRIVILEGE 
subopt ions can be set 
in SUPER, but currently 
are not supported in 
the system. 
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Table 


5. User Authorization Options and Subopt ions (cont.) 


Opt ions 


Subopt ions Comment 




SUPERD 

SUPERFFORM] 

SUPERW[SN] 

SYSC[ON] 

VOLINIT 


FEPR[IVILEGE] 


CO 

EXMFlyl] 

EXP M] 

FMR EAD] 

FMS[EC] 

GP[P] 

IN TCON] 

MA XM] 

MS[YSJ 

SCR[EECH] 

SNAP 

SP[CLMM] 

SYSLfOGJ 

TN[D] 


FEPS[EUDO] 


One or more FEP pseudo 
resources. 


FERE[SOURCES] 


One or more FEP resources. 


HS[ET] 




KEY 




L[AST] CP[ROC] 




ME[iylORY] 




NA[TIVEL] 




OUtTPUTPRIO] 




PA[SSWORD] 




PP[RIVILEGE] 


CONTRLC 
CNTRLD 
EF[T] 
EL 

LA[BEL] 

NETCON 

PADMIN 

PIGC 

PIGD 

PIGETTE 

RATES 

REPLAY 

SPIDERC 

SPIDERD 
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Table 5. User Author i zot ion Options and Subopt ions (cont.) 



Opt ions 



Subopt ions 



Comment 



PRIO[B] 
PRIV[ILEGE] 



PRO[rRE] 
PStEUDO] 

QU[AN] 
RE[SOURCES] 
•S[JkCCOUNTINGl 
SER[VICES] 



SET[UPl 
ST[EPACCNT] 



SU[PER1 

SUPERA[UTH] 

SUPERD 

SUPERFfORM] 

SUPER1M[SN] 

SYSC[ON] 

VOLINIT 



ASfAVE] 
CFrEP] 
DI[SPJOB] 
EXM[M1 
M] 



lAG] 
EAD] 
EC] 



EXP 
FMD 

rm 
Ryis 
GP[P] 
lOQ 
lOQW 
JI[T] 
MAXlyj 
MFEP 
MS[YS 
PM 
SP[ClJy|yi1 
SYSCrONl 
SYSLIOG] 
TN(D] 



One or more pseudo 
resources. 



One or more resources. 



DO 

FP[OOLS] 
LO 

MA[XJOBPRIO] 

P[DIS] 

PO 

TDtlSl 
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Table 5. User Authorization Options and Suboptlons (cont.) 


Opt Ions 


Suboptlons Comment 


TI[ME] 




\W[SN] 





Generally, the system manager can assign any option or suboption, but o project 
administrator con assign options or suboptions only up to the level of authorization 
that the project administrator's own authorization record allows. 



The following example illustrates the subset of SUPER options needed to set up a new 
user authorization record. In this example, all field values that con be token from the 
default record ore taken from the default record. 
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CMD*CREATE ABCOOI .001 SMITH 




OPT*HSET«USER < — The home packset must always be specified 


(or It defaults to |SYS) . 




OPT*FACCOUNT < — The file management account may be 


created 


SUB«READ«?,WRITE=ABC? via SUPER or the PIG processor can 


be in— 


SUB*GR»500 voked separately. 




SUB« 




OPT* 




More typically, a series of options like the following will be 




used to create a user: 




CMO*CREATE ABC002 . 002RO6ERS 




OPT*HSET»USER 




OPT*PASSWOR[>ibPHIL < — Setting of initial user passwords 


s an 


instat tat ion pol icy. 




OPT»PROFILE«VIP7801 < — Typically the account creator will 


need to 


OPT*WShMJPSTAIRS consider the choice of the default 


termi nal 


and the default output destination 


for each 


user . 




OPT*PRIVILEGE <— Typically, the ASAVE privilege should be 


SUB*DISPJOB 0,B,G,T set to YES. Note that suboption mode is 


entered and the modes that the privilege 


is to be applied to are specified. 




SUB* 




OPT ♦ FACCOUNT 




SUB*READ-? , VHR I TE-001 ? . CGMEM«40 , NOL I ST-XY2? 




SUB* 




OPT* 





A user can also be created from another user, as follows: 



CMD*CREATE ABC003 . 003GOMEZ 


FROM ABC002.002ROGERS 


OPT*BUDGET 


In this case, ABC003 , 003GOMEZ is created 


SUB*MCHARGES»200 . 00 


with ait field values set the some as for 


SU6*BKACCES&-N0 


ABC002,002ROGERS, except that the account 


SUB*BUDLIIi<h«YES 


is to have a maximum of accumulated charges 


SUB* 


of $200.00, no bankruptcy access, budget 
limits are to be checked at each job step. 


OPT*STEPACCNT 


OPT* 


and job step accounting is to be performed. 
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The following example creates a different kind of user authorization record in which 
only batch jobs can run under the account. The account will be able to use two P6 
pseudo resources and three disk packs. Its workstation of origin is named SHAMOKIN. 
The maximum time for any job in batch should be 6 hours, and the defoult time is 30 
minutes. 



CMD*C ABC0e4.ee4BATCH 

OPT •ACCESS B, ONO, G«NO, T-NO 

OPT ♦PSEUDO 

SUB*P6 B-2 

SUB* 

OPT^RESOURCES 
SUB»DP B-=3 
SUB* 

OPT*WSN«SHAMOKIN 

OPT*TIME MAX B-360: TIME DEF B>-30 

OPT* 

CMD* 



Requesting Help 

Online documentation on SUPER can be listed at the terminal as SUPER is being used. 
Online documentation can be requested both prior to entering a command and in response 
to an error diagnostic. 



Requesting Online Documentation Before Entering a Command 

Entering HELP in response to the CMD* prompt will result in display of the following 
message. 
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CP-6 communication management, project and user authorization, and 
forms control functions ore implemented through the SUPER processor. 



To obtain more HELP information, see 



HELP (SUPER) TOPICS 
HELP (SUPER) COMMANDS 

HELP (SUPER) command PARAM 

HELP (SUPER) command DESCRIPTION 

? 

?? 



Displays topics. 
Displays a list of SUPER 
commands . 

Displays parameters associated 
with a particular command. 
Displays description associated 
with o particular command. 
Displays next level of HELP 
messoges . 

Displays all levels of HELP 
messages. 



As this message suggests, SUPER HELP consists of different kinds of information about 
SUPER. The different topics of SUPER information for which online documentation exists 
can be listed by entering HELP TOPICS, which will result in the following display: 
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I HELP (SUPER) TOPICS 

ALIGN.SUBOPT IONS BAN.SUBOPT IONS BUDGET.SUBOPT IONS 

CHARSET_OPTIONS COMMANDS COMMUNICATIONS COMMANDS 

COMMUN I CAT I ON.PROF I LE_OPT I ONS CONSOLE CONSOLE.OPT I ONS CONTROLLER 

CREATE CREATE_CHARSET CREATE_COMMANDS CREATE_FORM 

CREATE_FORM_GRAPH ICS CREATE^PROJ ECT CREATE^PSEUDO 

CURSOR_PROFI LE_OPTIONS DELETE^CHARSET DELETE_COMMANDS 

DELETE^FORMS DELETE.USERS DEVICE DEVICE.ATTRIBUTE_OPTIONS 

DEVICE.FOR^LINE DEVICE.OPTIONS ENTRY_OPTIONS ENTRY.TEXT 

F I E LD.PROF I LE^OPT I ONS FORM.COMMANDS FORM_OPT I ONS 

GRAPH I CS_A L I GN^SUBOPT I ONS GRAPH I CS_BAN_SUBOPT I ONS 

GRAPH I CS.ENTRY^OPT I ONS GRAPH I CS_FORM_OPT I ONS GRAPH I CS.PROF I LE^OPT I ONS 

HELP HELP. INDEX INVOKING^SUPER LINE LINK 

L I NK_PROF RETORTIONS LIST LIST_CHARSET L I ST^COMMANDS 

LIST_FORM LIST^PROJECT LIST_TDEVICE MAKEME 

M I SC.PROF I LE.OPT I ONS MOD I FY MOD I FY^COMMANDS MOD I FY_PRO J ECT 

NOTATION OPERATIONAL_PROFI LE^OPTIONS PACKSET^SUBOPTIONS PRIVI LEGES 

PROFI LE PROFI LE_OPTIONS PROFI LE_OPTION_SUMMARY PROFI LE.TYPES 

PROJ ECT_COMMANDS PROJ ECT_OPT IONS RELATED_FI LES REMOVE 

REMOVE_CHARSET REMOVE_COMMANDS REMOVE.FORM 

REMOVE_PROJECT STATION TERMINAL TIE TIE.PROJECT 

TIMING_PROFILE_OPTIONS UNTIE UNT I E^PROJ ECT USER_COMMANDS 

USER^OPT I ONS V I RC I R.PROF I LE_OPT I ONS VI RTUAL_C I RCU I T 

WSN 



The user can request: 

o A Met of SUPER commands 

o Information about a specific SUPER command 
o A list of SUPER options or suboptions 

o Specific information obout the options or suboptions in a category 
o Other kinds of information. 

The following is the display that results when HELP COMMANDS Is entered in response to 
the CMD* prompt. 
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A list of SUPER commands ond their 


definitions con be accessed by 


typi ng 


HELP (SUPER) COMMUNICATIONS.CMDS 


for SUPER communications commands. 


HELP (SUPER) PROJECT^CMDS 


for SUPER project authorization 




commands. 


HELP (SUPER) USER.CMDS 


for SUPER user authorization 


commands. 


HELP (SUPER) FORM_CMDS 


for SUPER line-oriented and graphic 




form commands. 



The following is the display that results when HELP USER.CMDS is entered in response to 
the CMD* prompt. 



A list of user authorization commands and their definitions con be 
accessed by typing a ? or a ?? after this message. To obtain 
definitions of individual user authorization commands, type 

HELP (SUPER) USER.CMDS command 

where command is any of the following: CREATE. DELETE.USERS. LIST. MODIFY and 
REMOVE. 



The following is the display that results when ?? is entered. 
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CREATE 

Invokes the user authorization mode of SUPER. 
DELETE USERS 

Deletes oH and rebuilds default user definitions. 

LIST 

Displays user authorization information. 

MODIFY 

Alters an existing authorization. 

REMOVE 

Removes an existing outhor i zat ion. 



The following is the display that results when HELP CREATE is entered in response to the 
CMD* prompt. 



Fo rmat 

El r.laccountl. namel ^.^ 

[ {DEFAULT 



C[REATE] [.Jaccountl. nomel [FROM | [^]account2, name2|j 



Note that only the syntax is displayed. HELP information is orgonized hierarchically: 
the user can request each layer of information for a topic separately, or the user can 
request that all information for a topic be displayed. For example, the layers of 
information for a command include, in addition to syntax, parameter descriptions, a 
description of the command and, where appropriate, examples. Eoch of these layers can 
be displayed. For example. 
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CMD*? 

Parameters: 



accounti, name1 is the logon ID. This combination must be entered to goin access 
to the CP-6 system. The account is limited to 8 characters, the name to 12. The 
valid character set consists of alphanumeric characters plus the characters $ and :. 

FROM account?, name2 indicates that each item not explicitly specified at the 
option level is to be set to the value of the corresponding Item of the 
authorization record identified by this log-on ID. 

FROM DEFAULT indicates that each item not explicitly specified at the option 
level is to be set to the value of the corresponding item of the default 
authorization record. (The default record may be initialized by substituting the 
keyword DEFAULT for the account-name logon ID, i.e., CREATE DEFAULT. Use of the 
DEFAULT authorization permits the definition of many users with a minimum of 
effort.) 

If FROM is not specified. FROM DEFAULT is assumed. 



CMD*? 



Descri pt ion: 

This command invokes the user authorization mode of SUPER. Options that moy be 
entered in this mode can be accessed by typing HELP (SUPER) USER_OPTS. 



CMD*? 



No messoge available. 



Alternatively. ?? can be entered after the syntax is displayed to disploy all remaining 
information obout the command. For example: 
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Format ; 

M[ODIFY] [.]account1, name1 [FROM I [ . ]account2 , name2{1 

[ I DEFAULT |] 

CMD*?? 
Parameters : 

Gccountl, namel is the logon ID. This combination must be entered to gain access 
to the CP-6 system. The account is limited to 8 characters, the name to 12. The 
valid character set consists of alphanumeric characters plus the characters $ and :. 
Note that wildcarding is allowed for accounti and name1 (e.g., M[ODIFY] ?HOST, 
102?). 

account2, name2 indicates that each item not explicitly specified at the option 
level is to be set to the value of the corresponding item of the authorization 
record identified by this log-on ID. 

DEFAULT indicates that each item not explicitly specified at the option level is 
to be set to the value of the corresponding item of the default authorization 
record. 

Description: 

This command alters an existing user authorization. The options which may be 
altered can be accessed by typing HELP (SUPER) USER.OPTS. 



The following is an example of how to list options and then list specific information 
about an option. 
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CM)*HELP USER.OPTIONS 

A list of user authorization options con be accessed by 
typing a ? or a ?? after this messoge. To obtain 
definitions of individual options, type 

HELP (SUPER) USER.OPTS option 

where option is any of the following: 

ACCESS. BANNERTEXT. BILLING. BUDGET. CPROC. EXPIRE. FACCOUNT, 
FEBILLING, FEDBACCN. FEMACCTMEM. FEMFPR6. FEMINTS. 
FEMMEMORY. FEMTIME. FEPPRIVI LEGE. FEPRIVILEGE. FEPSEUDO. 
FERESOURCES. HSET. KEY. LAST.CPROC. MEMORY. NATIVEL, OUTPUTPRIO, 
PASSWORD, PPRIVILEGE. PRIOB, PRIVILEGE, PROFILE, PSEUDO, 
QUAN. RESOURCES, S.ACCOUNTING. SERVICES, SETUP. STEPACCNT. 
TIME. WSN 

CMD^HELP USER.OPTS BANNERTEXT 

BANNERTEXTn«}*[string]*[.user_alterable] | . user_a I terablej 

Specifies the text of o user banner field and/or the alteroble 
attribute of the text in the field, where: 

n is a numeric value, 1 through 9, that identifies 
the user text field. 

•string* is 0 to 80 ASCII printable characters that 
ore the text for the field. If string is null, the 
current contents of the text field will be deleted. 

•user.al teroble is either: 

,A[LTERABLE] specifies that the user can modify the 
contents of the text field (via the IBEX command LET). 
ALTERABLE is the default. 

.U[NALTERABLE] specifies that the user cannot 
modify the contents of the text field. 



Requesting Syntax Information After an Error Diagnostic 

Once a line entry has been started in response to any SUPER prompt, the SUPER user can 
request help by entering a single or double question mark. SUPER will list the next 
expected entry on the line. For exa»pte: 
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CM)*CREAT£ ABC002 . 002RO6ERS 
OPT*HSET-? 



Syntax error 

OPT*? 

Acceptable input here is: 

an alphabetic name (plus '0123456789:$'). 
I DP 



SUPER displays a list of the kinds of input it is expecting: either an alphabetic name 

(as qualified) or | or DP. (In fact. DP would be followed by § and then an alphabetic 

name, and § would be followed by on alphabetic name. Entering the expected data and 

then another question mark would reveal this.) The line can then be reentered with the 
correct volue. 

If a line is entered in response to any SUPER prompt and SUPER detects a syntax error, 

SUPER will diagnose the error. The SUPER user can request help by entering a single or 
double question mark. For example: 



CMD*CREATE ABC002 . 002RO6ERS 
OPT*ABCDEF 



Syntax Error 

OPT*? 

Acceptable input here is: 

one or more blanks (and/or o "comment") 
the end of the command (possibly with a 
•S/_ACCOUNTING ? 
BAANUM BI/LLING BU/DGET 
FA/CCOliNT FEBI/LLING FECX/TMEM 
FEMF/PRG FEMI/NTS FEMMEAlORY 
FEPR/I VI LEGE FEPS/EUDO 
KEY L/AST MEAIORY 

PA/SSWORD PP/RIVILEGE 
PS/EUDO QU/AN Q/UIT 
ST/EPACCNT TI/ME WS/N 

DPT* 



comment") . 
?? AC/CESS BANNERTEXT 

CP/ROC E/ND EX/PI RE 

FEDB/ACCN FEMA/CCTMEM 
FEMTIAIE FEPP/RIVILEGE 
FERE/SOURCES HEL/P HS/ET 

NA/TIVEL OU/TPUTPRIO 
PRIO/B PR/I VI LEGE PRO/FILE 

RE/SOURCES SERAICES SET/UP 
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SUPER displays o list of the keywords that can be entered. (In this case a list of the 
user authorization field names, plus the HELP single and double question marks and the 
keyword END. SUPER also explains that blanks can precede the next part of the entry, 
that a quoted comment can be entered, or that the response can be a null line ("the end 
of the command"). SUPER indicates the minimum portion of the keyword by terminating it 
with a slash.) The line can then be reentered with the correct value. 



Listing user Authorization Records 

The SUPER command LIST is used to list user authorization records. The user can list: 

o an entire user authorization record. 

o selected fields in a user authorization record. 

o the default record (either the system or project default record) for a specified 
user . 

The LIST command is entered, and then the option desired is specified. To request 
listing of an entire record, the following is specified: 



CMO*LIST ABC0ei,eei SMITH 

OPT»ALL 

OPT» 



< — Requests a listing of the entire record. 



A user authorization record similor to the one pictured earlier 
in this module is listed. 

The options that can be specified to request selected fields in 
a user authorization record are: 



♦Sr^ACCOUNTING] 
AC[CESS] 
ALTFERABLE] 
BAN[NER] 



TCH] 
TNUM] 
LLING] 
DGET] 
ROC] 
PIRE] 
CCOUNT] 



BA 
BA 
BI 
BU 
CP 
EX 
FA 
FE 

FEBI [LLING] 
FECG 

FECXfTMEM] 
FEDBLACCN] 
FEGlHOST] 



FEH[ANDLER] 

FEMAfCCTMEM] 

FEMI[NTS] 

FEMMEfMORY] 

FEMTI[ME] 

FEPPFRIV] 

FEPR IV] 

FEPS EUOO] 

FERE[SOURCE] 

FEU[SER] 

G[HOST] 

HS[ET] 

KEY 

LtAST] 

ME[MORY] 

NfATIVELj 

OINLINE] 



OUlTPUTPRIOl 

PA[SSWORD] 

PPRIV[ILEGEl 

pRiors] 

PRIV[ILEGE] 

PRO[FILE] 

PSfEUDO] 

QUFAN] 

RE[SOURCES] 

SERfVICES] 

SET[UP] 

STfEPACCNT] 

TIIME] 

TP 

W[SN] 



Most of the user author I zot i on LIST options are the some as or ore similar to user 
authorization record field nmes. However, note that when listing banner text the 
option specified Is BANNER not 6ANNERTEXT. These options con be entered one per line or 
multiple options can be entered on one line, separated by semi-colons. For example: 

CMD*LIST ABCe€1,eeiSMITH 
OPT^ACCESS ; PROFI LE ; WSN 
OPT* 



will couse o listing similar to the following: 
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ABCeei ,001 SMITH 



PROFILE 
TTY 

ACCESS 
B: YES 
G: NO 
0: YES 
T: NO 
F: NO 



WSN 
LOCAL 



1 users listed. 



The user authorization LIST options FE, GHOST. ONLINE, and TP do not themselves request 
a listing. They are used os listing qualifiers to limit listing by mode. For exomple: 

CMD^LIST ABC001 .001 SMITH 
OPT»ONLINE 

OPT*BILLING;MEM;TIME;QUAN;PRIOB 
results in the following listing: 



ABC001 .001 SMITH 

BILLING MEM MAX MEM DEF TIME MAX TIME DEF QUAN PRIOB 
0: 1 511 128 9999 9999 0 0 



. . 1 users I i sted. 



The specification: 
CMD*LIST DEFAULT 

will cause the system user default record (pictured In module 4-1) to be listed. 
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AdministBt ing user Authorizations 

SUPER features a number of commands to enable the project administrator or system 
manager to maintain authorization records once they are created: 

o the MODIFY command allows the authorized administrator to change the contents of the 
record. 

o the REJyIOVE command allows the authorized administrator to delete an authorization 
record. 

o the DELETE USERS command ollows the project administrator to delete oil user 

author i zot i on records that that administrator is outhorized to mointoin. In the 
cose of 0 project admi n i st rotor , that is oil records in the current project and all 
subordinate projects. (In the cose of the system manager, this command must not be 
used. Its effect will be to develop all records except the system-built records 
(see Modu le 4-1 ) . 

The following is on example of using the MODIFY and REMOVE commands: 



CMD»MODIFY ABC002 , 002ROGERS 


OPT^PRIV 




SUB*MAXM B,0,G < — 


Sets the MAXimum Memory allocation privilege for 




batch, online, and ghost modes. 


SUB* 


OPT^PPRIV 




SUB^EFT B.O.G <— 


Sets the EFT processor privilege for batch, 




online, and ghost modes. 


SUB* 


0PT*SERVICE 




SUB*MAXJOB B»9.C>*9 <— 


Sets the highest priority the user may assign to 




a batch job at 9 in batch and online mode. 


SUB* 


OPT* 




CMD*REMOVE A6C003.003GOMEZ(FACCOUNT) 




Note that if FACCOUNT is not specified as 




part of the REMOVE command. The associated 




file management account will not be removed. 




The PIG processor will have to be Invoked 




to remove the file management account. 
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Defining and Using a CP-6 Network 



A CP-6 network consists of some combi not ion of the following three types of nodes: 

1. Host nodes. A host node is a CP-6 host system. 

2. Local FEP nodes. A local FEP node is connected to a host via a coupler. 

3. Remote FEP nodes. A remote FEP is connected to a local FEP through an HDLC line. 

This module describes how to define end connect the nodes of a CP-6 network and how to 
manage the network once it hos been created. 

If the network is to consist only of host nodes and local FEPs, the network can be 
defined via the TIGR processor. If the network is to consist of host nodes, local FEPs 
and remote FEPs the process of defining and maintaining the network involves the use of 
several processors as follows: 



Processor 
NETCON 



PIGETTE 
SUPER 

TIGR 



Funct ion 

Defines the node number for remote 
FEPs and the node name for local and 
remote FEPs. 

Configures the HDLC channels for 
both local and remote FEPs and 
associates link and virtual circuit 
information with channel Information. 

Defines the boot image. 

Writes the boot diskette. 

Defines physical link to network 

Defines the link destination 

Defines the path connecting local 
FEPs to the system. 



Command 
DEFINE 

CONFIG 
SET 

DEF LINK 

DEF VIRTUAL CIRCUIT 
FEP 



Creating Local FEPs on a Network 



The TIGR processor is used to define the path connecting FEPs to the system. The FEP 
command: 

o assigns o FEP a number 

o defines the Input/Output Multiplexer (lOM) to which the FEP is connected. (lOM 
ports are defined via the TIGR processor lOM command.) 



o specifies the channel over which the FEP is connected to the host. 
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o and can be used to specify other FEP attributes (i.e., the size of the input and 
output circular queues and the initialized partition status of the FEP.) 

The TIGR processor MON command is used to establish a maximum number of nodes on the 
system. 

There is only one default handler defined as part of the boot image for local FEPs: the 
ASYNC handler. The NETCON processor must be used to define handlers other than the 
ASYNC handler for a locol FEP. The NETCON processor may also be used if the system 
manager wishes to assign a name (as well as a number) to the local FEPs in the system. 

The following example illustrates use of the TIGR command to define local FEP 9 and use 
of the iylON command to define a maximum of 50 nodes in a network: 



FEP NAME-FEP 9 . 10M#-e,CHAN-33.0UTQSZ-4; INQSZ-2 
MON ; I I 



Output and input queues 



N0DES-5e,; 



These TIGR commands that help configure a network are included in a TIGR device 
configuration deck (see Module 3-1). 



Adding Remote FEPs to a Network 

Once the local FEPs are defined, the remote FEPs can be added to the system. Each 
remote FEP must be connected to a local FEP. 

The physical connection between a remote FEP and a local FEP must be established via 
HDLCX25 linkage in both directions: that is, a remote FEP must be connected to a local 
FEP via an HDLCX25 physical link, and a local FEP must be connected to a remote FEP via 
on HDLCX25 physical link. The HDLCX25 linkage is defined via the SUPER CREATE VIRTUAL 
CIRCUIT command and the H0LCX25 handier must be explictly included in the boot image for 
both the local and remote FEPs. 

The sequence of steps for attaching a remote FEP to a network is: 

1. Use NETCON to define the remote nodes and node names. 

2. Use SUPER to set up links and virtual circuits. That is, the SUPER processor is 
used to: 

o Create the link profiles required to connect a local FEP and a remote FEP. 

o Create virtual circuit profiles, one to be associated with each of the links 
that are to be creates. 

o Create the links between the local and remote FEPs. 
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o Creole a virtual circuit for eoch link. 



3. Use NETCON to: 

o associate TEPs, remote FEPs ond remote FEP linlce with the SUPER- defined linic 
nomes by using: 

- the CONFIG commend to configure the channels. 

- the DEF LINK command to establish a communication channel for the remote FEP 
to use before communication with the host is estoblishd. 

o set the boot information for the remote FEP(s) ond the local FEPs. being sure 
to include for both an HDLCX25 link. 

4. Use PIGETTE to write the boot diskette and initialize o blank diskette for dumps. 

5. Boot the system. 



Defining the Remote Nodes and Node Names 

Each node in the network has a unique number from 0-255 and a one to eight character 
nome associated with it. Either the node number or the node name con be used in NETCON 
to identify the node. The node number for local FEPS is defined via the TIGR processor 
(see the section Defining Local FEPs. above). The node number for host nodes and for 
remote FEP nodes ore defined vio the NETCON processor DEFINE command. The names of all 
nodes ore defined via the NETCON processor DEFINE command. 

A remote FEP must be defined via the NETCON processor DEFINE NODE command before it can 
be booted. 

In the following example, the NETCON processor is invoked to define a remote FEP. node 
12 and assign it the node name L6XII. 



1 NETCON 

NETCON Cee HERE 

*DEFINE N0DE-12.N0DENAME-L6XII 

The next section describes how the SUPER processor is then invoked to define the linkage 
for this node* which will be connected to local FEP 9. 



Setting Up Links and Virtual Circuits 

A link is a communication line that uses HDLC protocol and is used to connect the nodes 
in a network. A link constitutes the physical and the frame levels of on X.25 
connection. A virtual circuit is a logical connection at a higher level than a link. 
Several virtuot circuits con be multiplexed on to one link. 

The links in the network must be defined via the SUPER processor CREATE LINK and CREATE 
VIRTUAL CIRCUIT commands before a remote FEP con be booted. For remote FEPs, one link 
must be defined for the local FEP and one link must be defined for the remote FEP. At 
least one virtual circuit must be defined on one of the end points of the linkage 
between two FEPs. 

Once the SUPER processor has been used to create the HDLCX25 linkage, the NETCON 
processor is used to configure channels, local FEPs, remote FEPs and remote links via 
the link names ossigned via the CREATE LINK and CREATE VIRTUAL CIRCUIT commands. 
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The SUPER processor CREATE LINK comnand creates link definitions. In the following 
exomple» links and virtual circuits are set up to link local FEP 9 to remote FEP 12. 
Note that links must be set up at both ends — at the local FEP and at the remote FEP 
ends. 



1 SUPER 








cp-6 SUPER cee 








CMD*CREATE PROFILE 


LINK12PR0 LINK 


< — 


Creates a link profile for the 








remote FEP 1 ink (link 12). 








LINK profile options ore specified 








in SUPER option mode. The LINK 








profile options that con be 








specified are defined in the 








LINK Profile Option Table. 


0PT*FRAME»512 




< — 


The maximum number of data bytes 








for the X.25 frame will be 512 








instead of the default of 128. 








Note thot in this example the 








same frame size will be used for 








both end of the link and for the 








virtual circuits in the link. 








If different frame sizes are 








specified, the frome size used 








is determined by negotiating down. 


OPT»CIRCUITS-10 




< — 


Specifies that 10 virtual circuits 








may be operational on the link at 








one time insteod of the default 








of 1. 


OPT*DEFAULT RESPONSE TIMER-O 


< — 


Specifies that there is to be 








no wait time if an incoming 








call does not specify explicitly 








a response time for this circuit. 


OPT^DEFAULT PACKET 


SIZE-512 


< — 


Specifies that, if an incoming 








call does not explicitly specify 








0 receive size, 512 bytes is to 








be used as the receive size 








instead of the defoult of 128. 


OPT*MODE-DCE 




< — 


In this example, no public 








data network is used. Therefore, 








one end in the connection must 








be declared to be DCE. 


0PT*RETRAN-5 




< — 


Specifies that, before moving 








to alternative oction, retransmission 








should be attempted five times 








instead of the defoult of 20 








times. 


OPT*END 









(cont. next page) 
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CMO*CREATE PROFILE LINK9PR0 LINK 


< — 


Creates another link profile for 


0PT*FRAME-512 




the local FEP 1 ink (1 ink 9). 


OPT*CIRCUITS-ie 




Note that all options specified 


OPT^DEFAULT RESPONSE TIMER-0 




for the local FEP link profile 


OPT»MO0E«DTE 




match the options specified for 


0PT*RETRAN-5 




the remote FEP link profile 


OPT ♦END 




except that the mode for the 






local FEP link is DTE instead 






of DCE. 


The next series of SUPER commands and profile options create two 


virtual circuit profiles that 


are named so that they can be associated 


with the local and remote FEP 


1 inks 


that are to be created. 


CMD*CREATE PROFILE LINK12VCPR0 VIRTUAL CIRCUIT 






Creates a profile for a virtual 






circuit for the remote FEP 






^reauired to enable HDLCX25 






communication links). 


OPT*RECEIVE SIZE"b512 


< — 


Soec i f i es that thA inaximiJiii 

w W V VII Ivw ^ll\JV Vllw fil\J^i ill Will 






dato s 1 of Dackftta from thft 

WWVw 9i&V Wl ^WvrxVh9 II will V 1 IV 






call recipient is 512 bytes 






^ t he same os the f raine size 






for the 1 i nk) . 


OPT*SEND SIZE»512 


< — 


Specifies that the maximum data 






size of Dockets sent to the cat 1 






recipient is also 512 bytes. 


OPT*RESPONSE TIMER-0 


< — 


Specifies that there is to be no 






wait after deciding to send an 






explicit flow control packet. 






The two kinds of flow control 






packets are positive acknow- 






ledgements (RRs) and negative 






acknowledgements (RNRs). 


OPT*RECEIVE WINDOW-? 


< — 


Specifies that the receive 






window size is 7 packets 






rather than the default of 2. 


OPT^SEND WINDOW-7 


< — 


Specifies that the transmit 






window size to the call recipient 






is to be 7 rather than the default 






of 2. 


OPT»RESPOND COMPLETE-NO 


< — 


Specifies that any complete data 






packet sequence is not to be 






acknowleged immediately. A 






complete data packet sequence 






is either a single packet that 






is not continued, or a sequence 






of continued packets that includes 






a final, non-continued packet. 


OPT*RESPONSE DELAY-4 


<— 


Specifies that 4 unacknowledged 






packets con be received before 






on explicit acknowledgement 






packet is generated. 


OPT^TYPE-PRIMARY 


< — 


Specifies the virtual circuit 






usage type. 


OPT* END 







(cont. next page) 
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CMD*CR PRO LINK9VCPR0 VI R CIR 


< — 


Creates the profile for a virtual 


OPT^RECtlVE SIZE=512 




Circuit to be associated with the 


OPT ♦SEND SIZE=512 




local FEP (LINK9). 


OPT ♦RESPONSE TIMER=0 




OPT^RECEIVE WINDOW/ 






OPT ♦SEND WIND0W=7 






OPT ♦RESPONSE COMPLETE-NO 






OPT ♦ T YP E«S ECONDAR Y 






OPT ♦END 






CMD^CREATE LINK LINK 12 


< — 


Creates a link definition. The 






LINK name can be 1—8 characters. 






Specifying the LINK command 






initiates SUPER option mode. 






Two options ADDRESS and PROFILE 






must always be specified. 


OPT ♦ PROF I LE«L I NK 1 2PR0 


< — 


Specifies the LINK profile for this 






link. The profile specified must 






already have been created through a 






CREATE PROFILE. .. LINK command. 


OPT • ADDRESS«>^0 


< — 


Specifies the address inserted in 






the calling address field of out- 






going call pockets. The value 






specified (90) is arbitrary. 






If a public data network is 






addressed, the PDN address would 






be specified. 


OPT ♦END 






CMD^CREATE VIRTUAL CIRCUIT 1 FOR 


LINK 


LINK12 






Creates a virtual circuit defini- 






tion for the remote FEP. Specifying 






the CREATE VIRTUAL CIRCUIT command 






initiates SUPER option mode. 


OPT ♦PROF I LE«L I NK 1 2VCPR0 




For network nodes, the PROFILE and 


0PT^ADDRESS=91 




ADDRESS options (as specified for 






the LINK example) ore specified, 






and the DESTINATION option must be 






specified as well. The address 






is the coll packet called address. 


OPT ♦DEST I NAT I 0N»L6 I X 


< — 


Identifies the node name of the 






local FEP (9) (as defined via 






a NETCON DEFINE NODE command) 






OS the circuit's destination. 






(In the case of a remote FEP, 






DESTINATION must point to a local 






FEP. ) 


OPT ♦END 




CMD^CREATE LINK LINK9 


< — 


Creates a link definition for 






the local to which the remote FEP 






is to be connected. 


OPT^PROFI LE«LINK9PR0 


< — 


Specifies the LINK profile for this 






link. The profile specified must 






already have been created through a 






CREATE PROFILE. . .LINK command. 


OPT^ADDRESS-91 


< — 


Specifies the oddress inserted In 






the calling address field of out- 






going call packets. Note thot 






this address is the same os the 






link oddress for VIRTUAL CIRCUIT 1 
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for LINK 12. When LINK 9 receives 
Q coll packet from LINK 12, the 
addresses will match. 

OPT*END 

CMD»CREATE VIRTUAL CIRCUIT 1 FOR LINK LINK9 

Creotes a virtual circuit defini- 
tion for the local FEP. 

0PT*PR0FILE»LINK9VCPR0 For network nodes, the PROFILE and 

OPT*ADDRESS»90 ADDRESS options (as specified for 

the LINK example) ore specified, 
and the DESTINATION option must be 
spec i f i ed as we I I . 

0PT*DESTINATI0N«L6XII <— Identifies the virtual circuit's 

dest i not ion. 

OPT ♦END 
CMD*END 



The SUPER processor MODIFY, REMOVE and LIST LINK commands are used to modify, remove and 
list link definitions. The SUPER: Communications Management section of the System 
Support Reference manual contains descriptions of the these commands. Presented below 
are some examples of the types of LINK definition and LINK profile displays that can be 
listed through the SUPER processor LIST LINK and LIST PROFILE commands. 



I SUPER 

CP-6 SUPER C00 

CMD*L LINK LINK9 <— Lists the LINK definition for 

local FEP 9. 

LINK LINK9 PR0-LINK9PR0 ADDRESS-9 1000000000000 

CIRCUIT PROFILE CUG DEST ADDRESS 
1 LINK9VCPR0 00 L6XII 90000000000000 

CMD*L LINK LINK12 <— Lists the LINK definition for 

remote FEP 12. 
LINK LINK 12 PRO>«LINK12PR0 ADDRESS»90000000000000 

CIRCUIT PROFILE CUG DEST ADDRESS 
1 LINK12VCPR0 00 L6IX 91000000000000 



CMD^L PRO LINK9PR0 
OPT»ALL 



LINK9PR0 

CALLS 
ALL 



Type » LINK 

CIRCUITS 
10 



<— Lists the LINK profile for 
local FEP 9. 

<— Values for all LINK Profile 
options (see the LINK Profile 
Options table) ore requested. A 
display of specific options can be 
requested instead. 



DFLT PACKET SET DFLT_RESPOND 
512 0 



(cont. next page) 
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DFLT WINDOW FRAME LC6N MAX WINDOKf 

2 512 0 2 

MODE RESPONSE DELAY RETRANSMISSIONS REVERSE 
DTE 1 5 Yes 

TIMEOUT WINDOW 

3 7 



CMD*L PRO LINK12PR0 
OPT»ALL 

LINK12PR0 



CALLS 
ALL 

DFLT WINDOW 
2 

MODE 
DOE 

TIMEOUT 
3 



Type = LINK 

CIRCUITS 
10 

FRAME 
512 

RESPONSE DELAY 
1 

WINDOW 
7 



< — Lists the LINK profile for 

remote FEP 12. 
< — Requests a display of values for 

all LINK profile options for the 

remote FEP. 



DFLT PACKET SET 
512 

LCGN 
0 

RETRANSMISSIONS 
5 



DFLT.RESPOND 



MAX WINDOW 

2 

REVERSE 
Yes 



CMD*L PRO LINK12VCPR0 



OPT*ALL 



LINK12VCPR0 



<— Lists a VIRTUAL CIRCUIT profile 
for a virtual circuit defined for 
the remote FEP. 
< — Requests a display of values for 
all profile options for the 
remote FEP virtual circuit (see 
the Virtual Circuit Profile Options 
table). A display of specific 
options can be requested also. 

Type « VIRCIR 



BACKLOG 
5 



COST 
100 



DELAYS 
60 



RECEIVE.SIZE 
512 



RECEIVE_THR 
NONE 



RECEIVE_WND 
7 



RESP_TO.CMP 
No 



RESPONSE DELAY 
4 



RESP.TIMER 
0 



RETRYS 
10 



REVERSE 
No 



SEhtt)_SIZE 
512 



SEND.THR 
NONE 



SEND.WINDOW 
7 



TIMEOUT 
200 



TYPE 
PRIMARY 
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Table 6. LINK Profile Options 



Option Description 



CA[ LLS]»| NONE | X25 | X29 | ALL{ 

Specifies the usage of a link for incoming calls. NONE indicates 
that no incoming colls are allowed. X25 indicates that all incoming 
calls except X29 colls are allowed. X29 indicates that only X29 
calls are allowed. ALL is a combination of X25 and X29. The default 
is ALL. 



CIR[CUITS]-value 

Specifies a value (1-255) that is the maximum number of virtual 
circuits that may be operational at one time on a link. The defoult 
is 255. 



DEF[AULT] PACK[ET SIZE)=} 128|256|512| 1024J 

Specifies the packet size to use if on incoming coll does not 
explicitly specify a receive size. The default is 128. 



DEF[AULT] RES[PONSE TIMER]»value 

Specifies the number of second (0-255) to wait before sending a 
pocket-level acknowledgement for circuits defined on the link. This 
option specifies the wait time to be used if an Incoming coll does 
not explicitly specify a response time for this circuit. 



OEF[AULT] WIN[DOW]-value 

Specifies the packet window size (2-7) to use if on incoming coll 
does not explicitly specify a Receive Window. The default is 2. 



FR[AME]-i 1 28 1 256 1 51 2 1 ie24| 

Specifies the maximum number of dato bytes that an X.25 information 
frame can contain. The default is 128. 



LCGN-volue 

Specifies the logical channel group number (0-15) for outgoing colls. 
The defoul t is 0. 



MAX[IMUM] WIN[DOWI]-value 

Specifies the maximum send window (2-7) on incoming colls for 
circuits on this link. When making or receiving calls, if the send 
window size parameter exceeds this value, this value is used. The 
default is 7. 
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Tqbia 6. LINK Profile Options (cont . ) 



Option Description 



RESP[ONSE] DEL[AY]»value 

Specifies the number (0-7) of unocknow I edged informotion frames that 
should be received before an explicit acknowledgement frame is 
generated. A value of 0 indicates that explicit acknowledgement 
fromes should only be generated in response to received commands with 
the poll bit set. The default Is 1. 



RET[RANSMISSION]=va I ue 

Specifies the number of retransmissions (0-255) that should be done 
before moving to an alternative action. This is CCITT parameter N2 
A value of 0 indicates an infinite number of retransmissions should 
be done. The default is 20. 



REV[ERSEl [-} Y[ES] | N[0] } ] 

Specifies whether or not to accept incoming calls that specify 
reverse charges. The default is YES. 



TIME[OUT]«value 

Specifies the time interval in seconds (1-255) that should expire 
after transmission of a frame before corrective action should be 
taken because a response was not received. This is CCITT porometer 
T1 . The defoult is 3. 



WI[NDaflf]-value 

Specifies the frome transmit window size (1-7). This is CCITT 
parometer K. The default is 7. 
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Table 7. VIRTUAL CIRCUIT Profile Options 


Opt ion 


Descript ion 


DEL[AYS]»value 


Specifies the amount of time in 


seconds (0-255) before an ot tempt 




is mode to reconnect a VC thot has 




been cleared for reasons other than 




a higher level initiated clear. A 




value of 0 indicates that no delay 




should be used. The default is 60. 


MAXV[IRCIR]»value 


Specifies the maximum number (0-255) 




of virtual circuits to be used in a 




connection between a pair of nodes. 




If MAXVIRCIR is less than MINVIRCIR, 




MINVIRCIR is used. The default is 




255. If only one virtual circuit is 




to be defined, efficiency will be 




gained if MAXVIRCIR is set to 1. 


MINV[IRCIR]>value 


Specifies the minimum number (0-255) 




of virtual circuits to be used in a 




connection between two nodes. The 




default for MINVIRCIR is 1. 




MINVIRCIR and MAXVIRCIR values ore 




specified or defaulted for each 




virtual circuit between two nodes. 




If multiple virtual circuits ore 




defined between a pair of nodes, the 




values for all MINVIRCIR/MAXVIRCIR 




for ail the virtual circuits defined 








some. Otherwise, the MIN/MAX range 




selected wilt be somewhat unpredict- 




able. 


M0DE=}DTE|DCEJ 


Determines the command and response 




addresses for frames, and affects 




logical channel number assignment 




and the outcome of a coil collision. 




If a connection involves a PDN. DTE 




should be specified. If no PDN 




is involved, one end must specify 




DTE. and the other end must specify 




DCE. The default is DTE. 


REC[EIVE] SIZ[E]«}128|256|51211024| 




Specifies the maximum data size of 




packets from the call recipient. 




If this value is larger than the 




frame size of the LINK profile, the 




frame size value is used. The 




default is 128. 


REC[EIVE] THR[OUGHPUT] 


1 NONE 1 75 1 1 50 1 300 1 600 1 1 200 1 2400 1 




4800 1 9600 1 1 9200 | 48000 \ 




Specifies the throughput class 




of the VC from the call recipient. 




This option is meaningful only 




if the connection is mode through 




a PDN, The default is NONE. 
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Table 7. VIRTUAL CIRCUIT Profile Options (cont.) 



Opt ion 



Descr I pt ion 



REC[EIVE] WIN[DOW]-value 



Specifies the transmit window size 
(2-7) for the call recipient. The 
default is 2. 



RES[POND TO] COM[PLETE][«jYES|NOn 

Specifies whether (YES) or not (NO) 
any complete data packet sequence 
should be acknowledged immediately, 
regardless of the response delay 
value. The default is YES. 



RESP[ONSE] DEL[AY]«value 



RES[PONSE] TI[MER]-value 



RETR[YS]»value 



RE[VERSE1 [- j Y[ES] | N[Ol \ J 



Specifies the number of unacknow- 
ledged packets (1-7) that 
should be received before on 
explicit acknowledgement packet 
is generated. If this value 
is larger than the receive 
window, the receive window value 
is used. The defoult is 1. 

The number of seconds (0-255) to 
wait after deciding to send an 
explicit flow control message 
(based on response delay and 
response to complete). If on 
implied flow control message is 
sent before the time expires, no 
flow control message needs to be 
sent. The defoult is 3. 

Specifies the number of consecutive 
unsuccessful call packets (0-10) 
that will be transmitted before the 
VC is declared lost. A value of 0 
indicates no maximum number of 
retries. The default is 10. 

Specifies whether or not reverse 
charging should be specified in the 
call packet. The default is NO. 



SEN[D] SIZ[El-l128|256|512|1024{ 

Specifies the maximum data size 
of packets sent to the cal I 
recipient. The default is 128. 

SEN[D] THR[0U6HPUT]«{N0NE 1 75 1 1 50 1 300 1 600 1 1 200 1 2400 1 
4800 1 9600 1 1 9200 j 48000 ( 

Specifies the throughput class of 
the VC to the call recipient. This 
option is only meaningful if the 
connection is made through a PDN. 
The defoult is NONE. 
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Table 7. VIRTUAL CIRCUIT Profile Options (cont.) 



Option Description 



SEN[D] WIN[DOVIf]»value Specifies the transmit window size 

(2-7) to the call recipient. The 
default is 2. 

TIME[OUT]»vaI ue The timeout value (3-255) used for 

timing out responses to call reset 
and clear packets. The default 
is 20e. 

TY[PE]«{P[RIMARY] |S[ECONDARY] |B[ACKUP] j 

Specifies usage type of the VC. 
PRIMARY specifies that the VC 
should always be used. SECONDARY 
Is intended to meet peek loads. 
BACKUP is intended as a temporary 
replacement for primary and 
secondary VCs. This option applies 
only to VCs associated with a 
multilink network connection. The 
defoult is PRIMARY. 



Configuring the Network 

NETCON determines the channels that can be supported and thereby determines the kinds of 
handlers that con be downline loaded. 

A channel table is created in each FEP. The channel table contains one entry for each 
channel connected to the FEP. Each entry contains flogs and parameters that specify how 
0 given channel is to be used. These values for the channel table ore defaulted. (The 
DEFAULT command is used to set and change the default line configuration criteria for a 
handler in the FEP.) The system manager con change the defaults. The channel table 
entry also contains the current channel status (i.e., availability) date. These values 
con also be changed by any of several NETCON commands. Refer to the section Maintaining 
a Network, below, for more information on changing channel table defaults and changing 
channel status. 

After the NETCON processor has been used to define remote node numbers and all node 
names and the SUPER processor hos been used to define the links and virtual circuits, 
the NETCON processor is again invoked to configure the system. In the following 
example, the remote FEP defined as node 12 with the node name L6XII is configured. 
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INETCON 

NETCON C00 HERE 

♦SEL N«12 < — Specifies which node is to be configured. 

♦DEFINE LINK .5600 <— Specifies that chonnel 5600 is to be 

used to communicate with the network 
before establishing communication 
with the host. 

♦CONFIG .5600 LOGON* * LI NK12* , ENABLE*YES.REENABLE=YES 

Specifies the configuration for channel 
5600 (the channel on FEP 12 that is one 
of the end points of the 9<->12 link). 

♦SEL N=k9 < — Specifies node 9, the local FEP. is to be 

configured. NO DEFINE LINK command is 
required on the local side. 

♦CONFIG .5400 L0G0N=aiNK9* .ENABLE«YES.REENABLE=YES 

Specifies the configuration for channel 
.5400 (the channel on FEP 9 that is one 
of the end points of the 9<->12 link). 



Note that although there is only one link being configured, the two ends of the link 
(that is the local end and the remote end) must be configured. 

The following figure indicates how the FEP linkage is configured. 
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Figure 5. Sample Network Linkage 



Setting the Boot Information 

NETCON maintains the boot information about each PEP and each FEP's handlers. Through 
NETCON, control parameters can be set and changed that wilt influence performance 
characteristics for both the PEP and the handlers in the PEP. 

Por a local PEP, the handler information need be set only if the handler is a special 
handler. Por a remote PEP. all handlers must be explicitly defined before the remote 
PEP can be booted. Handler information is configured via the NETCON processor SET 
BOOTINPO command. 

In the following example, the boot image is created for the remote PEP and for the local 
PEP. 
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♦SEL N-12 



*SET BOOT INFO <— 

Monitor fid (MrPEP.iSYS) <— 

Number of handlers 4 < — 

Hondler name NODEADMN < — 

Hondler fid NODEADMN. : SYS <— 

Hondler name HDLCX25 < — 

Handler fid HDLCX25.:SYS <— 

Handler name ASYNC < — 

Handler fid ASYNC. : SYS <— 

Handler name UNITREC < — 

Handler fid UNITREC. :SYS <— 

Library account :SYS < — 

♦SEL N-9 <— 

♦ SET BOOT INFO <— 

Monitor fid (M:FEP.:SYS) <— 

Number of handlers 5 < — 

Handler name NODEADMN < — 

Handler fid NODEADMN. : SYS <— 

Handler name COUPLER < — 

Handler fid COUPLER. : SYS <— 

Handler name HDLCX25 < — 

Handler fid HDLCX25. :SYS <— 

Handler name ASYNC < — 

Handler fid ASYNC. :SYS <— 

Handler name BISYNC < — 

Handler fid BISYNC. : SYS <— 

Library account :SYS < — 



Selects the remote FEP for further 
processing. Note that FEP 12 is going 
to hove a boot diskette. It will not 
be booted over a coupler from a host 
boot image. 

The boot image information is defined. 
Identifies the LCP6 monitor run unit. 
Specifies the number of handlers to boot. 
Specifies the name of the first handler. 
Specifies the fid of the first handler. 
Specifies the name of the second handler. 
Specifies the fid of the second handler. 
Specifies the name of the third handler. 
Specifies the fid of the third handler. 
Specifies the name of the fourth handler. 
Specifies the fid of the fourth handler. 
Specifies the Library Account. 



Selects the local FEP for further 
processi ng. 
The boot image 
Identifies the 



information is defined. 
LCP6 monitor run unit. 



Spec 
Spec 
Spec 
Spec 
Spec 
Spec 
Spec 
Spec 
Spec 
Spec 
Spec 
Spec 



fies the number of handlers to boot, 

fies the name of the first handler, 

fies the fid of the first handler, 

fies the name of the second handler, 

fies the fid of the second handler, 

fies the name of the third handler, 

fies the fid of the third handler, 

fies the name of the fourth handler, 

fies the fid of the fourth handler, 

fies the name of the fifth hondler. 

fies the fid of the fifth handler, 

fies the Library Account. 



Note that in interactive mode the system manager is prompted to enter the monitor fid, 
the number of handlers, and, for each handler, the handler name ond the hondler fid. 



Writing the Boot Diskette 

Before a remote FEP con be booted, the PIGETTE processor is used to create a bootstrap 
diskette for the remote FEP connected to a local FEP. The boot diskette contains the 
LCP~6 monitor, and temporary diagnostic dump areas, as well as the boot image for the 
remote FEP. The PIGETTE processor uses records in the :NETCON file to describe the boot 
image. The diskette is a doub I e~s i ded , double-density, 5-1/4 inch diskette. 

This diskette must be loaded at the remote FEP. This diskette will also be read when o 
software crash is detected by a remote FEP to recover the remote FEP's monitor. 

When a remote FEP detects a software crash, the remote FEP automatically dumps 
information to its diskette. This Information will be sent to the FROG processor. 
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The PIGETTE processor BUILD command is used to create a boot image for a remote FEP. To 
creote the boot imoge: 

o The NETCON processor DEFINE command must be used first to define the remote FEP. 

o The PIGETTE processor is then invoiced. When it is. the VOLINIT command must be used 
first to initialize the boot diskette. 

o Then, the PIGETTE processor BUILD command is used to build the boot image on the 
diskette. 

For example, to build the boot diskette for FEP 12 (the remote FEP). the system manager 
does the f ol lowing. 



IPIGETTE 




C00 PIGETTE here at 15:57 


10.28 on 08/24/84 


Oink: VOLINIT FEP 1 DRIVE 


1 (TYPE-RFEP) 


. .VOLINITing 




VOLINIT complete. 




Oink: BUILD 12 OVER FEP 1 


DRIVE 1 


. .copying 




COPY complete. . 




Oink: L FEP 1 




Diskette on FEP: 1 Drive' 


1 


Created on 15:58 08/24/84 




Built for use on FEP 12 




Oink: END 




PIGETTE exiting. 





These commands load and initialize a diskette in drive 1 of FEP 1. and create a boot 
diskette that will eventually be used in FEP 12. Note the use of the PIGETTE processor 
LIST command to display information about the diskette. 

The PIGETTE processor MOVE command is used to move data between an actual diskette in a 
FEP drive and a virtual diskette stored in a CP-6 keyed file. This use of PIGETTE is 
described in the Section PIGETTE: Diskette FEP Initialization in the System Support 
Reference Manual . 



DisF>laying NETCON Information 

The NETCON processor DISPLAY command can be used to display different kinds of 
information about the network. Some of the more common forms of the NETCON processor 
DISPLAY command, and the resulting displays are listed below. Refer to the Section 
"NETCON: Network Configuration" in the System Support Reference Manual for a more 
complete treatment of the DISPLAY command syntax and for additional samples of DISPLAY 
output . 

The DISPLAY NET\MORK command displays a listing of the network nodes. 
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•DI NETWORK 




Nodal 


Name 


TvDA Control 


0 


L66A 


Host 


1 


L6I 


FeD L66B 


*> 
z 


1 AT T 


Feo L666 


3 


L6III 


Fep L66B 


4 


L6IV 


Fep L66A 


5 


L6V 


Fep L66B 


6 


L6VI 


Fep L66C 


8 


L6VIII 


Fep L66A 


9 


L6IX 


Fep L66B 


10 


L6X 


Fep L66B 


11 


L6XI 


Fep L66B 


12 


L6XII 


Fep L66B 


13 


L6XIII 


Fep L66B 


15 


L6XV 


Fep L66B 


20 


L66B 


Me 


21 


L66D 


Host 


22 


L66C 


Host 


30 


DVFEP 


Fep L66A 


32 


bVFEP 


Fep L66A 



The DISPLAY LINKS comniand displays link Information (includino the number of links for a 
node, the number of eoch link and the link line specification). 



*SEL N-12 
•DI LINKS 

Link information for node L6XII 
Number of I inks « 1 
Link! 0 - .5600 



The DISPLAY CONFIG command displays configuration information for the specified line on 
the selected node. 
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*DI CONFIG .5600 

Line Configuration for Node| 12(L6XII 

LINE SPEED: 

Auto Spaed D/C 

LOGON: 

Logon String LINK12 

Echo Logon D/C 

Prof i le None 

Flow control D/C 

Input D/C 

Solutot ion D/C 

Remote Term 

Enable Yee 

Read time out 0 

Logon Time out 0 

Hardwi re No 

Drop DTR D/C 

Disable on Host Down... No 

Resource code None 

Block 0 

Remote Debug D/C 

•DI CONFIG .5400 

Line Configuration for Node| 9(L6IX 

LINE SPEED: 

Auto Speed. . . .D/C 

LOGON: 

Logon String. . . .LINK9 

Echo Logon D/C 

Prof i le None 

Flow control D/C 

Input D/C 

Sal utot ion No 

Remote Term 

Enable Yes 

Read time out 0 

Logon Time out 0 

Hardwi re No 

Drop DTR D/C 

Disable on Host Down... No 

Resource code None 

Block 0 

Remote Debug D/C 



) CHANNELl .5600 Terminal id 
Speed 0 



Output D/C 

Break Required D/C 

Buffer Size 0 

ReenabI e Yes 

Trans Proc Timeout 0 

Clocking D/C 

Kilt on Host Down No 

Attribute 0 

Unblock 0 

Debug D/C 



) CHANNELl .5400 Terminal id 
Speed. . . .0 



Output D/C 

Break Required D/C 

Buffer Size 0 

Reenable Yes 

Trans Proc Timeout 0 

Clocking D/C 

Kill on Host Down No 

Attribute 0 

Unblock 0 

Debug D/C 



The DISPLAY BOOTINFO command displays FEP boot handler and library data for the 
specified node. For exomple: 



CE60-00 



Displaying NETCON Information 
Module 5-1 



115 



•SEL N=9 
•DI BOOT INFO 

Boot Information for Node L6IX 

Monitor Fi d - M: FEP. ;SYS 
Number of Handlers « 5 
Handler |1 Name - NODEAOMN 
Handler |1 Fid « NODEAOMN .: SYS 
Handler §2 Name « COUPLER 
Handler |2 Fid = COUPLER. : SYS 
Handler |3 Name = HDLCX25 
Handler |3 Fid « HDLCX25. :SYS 
Handler #4 Name « ASYNC 
Handler #4 Fid = ASYNC. : SYS 
Handler |5 Name « BISYNC 
Handler #5 Fid « BISYNC. : SYS 
Library account « :SYS 



Booting the System 

The boot process differs for local FEPs and remote FEPs, Further, the booting differs 
for a tape boot/hardware recovery and for a software recovery. Regardless of these 
differences (described in section 4 of the System Support Reference Manual)* once 
contact is established via the link channel to a local or remote FEP, connection is 
established throughout the CP--6 network: all nodes ore informed of the connect point. 

For initial booting, an operator must always hardware boot a remote FEP. The remote FEP 
boot diskette is always placed in channel 400 at the remote FEP to perform the hardware 
boot . 



Through NETCON, an online user con enable and disable lines and otherwise affect a 
line's availability, and con change FEP control parameters that will influence 
performance characteristics. 

The NETCON commands used to modify the network and their functions are listed below: 



Maintenance Through NETCON 



Command 



Chonge Function 



CONFIG 



Change line configuration parameters (i.e., the 
default flogs and parameters in a FEP 
Channel Table that specify how the channel is to 
be used. 



DELETE 



Delete a node or pseudo resource. 
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DISABLE 
DISCONNECT 
ENABLE 
KILL 



Change channel line availability. 



DISPLAY 



Display the current values of boot information, the 
network nodes, pseudo— resources, or NETCON 
controlled parameters. 



PARTITION 
RETURN 



Remove channels from system use and make them 
available for test and diagnostics, and return them 
to system use. 



SELECT 



Select a network node or handler for display/ 
change operations. 



SET 



Change NETCON controlled porameters on a per host, 
per FEP or per handler basis. 



Note that the CONFIG, DISABLE, DISCONNECT, ENABLE, KILL. PARTITION, and RETURN commands 
can all identify terminals, controllers, and subdevices via: 

o a hexadecimal chonnel number (which must be preceded by a period) that is the 
address of the physical channel corresponding to the terminal. 

o the terminal name as defined via SUPER. 



Changing Line Configuration Parameters 

Line configuration options define the class of device, set line values such as buffer 
sizes, character transmission blocks, line status, input/ output characteristics, CP-6 
environment characteristics (the logon, the profile) for the line and many others. The 
NETCON Line Configuration Option Table in the System Support Reference Manual details 
the options and the parameters that they control. 



Changing Boot and Handler Parameters 

The procedure to change a node definition is to: 

1. Use the NETCON processor SELECT command to select the node. 

2. Use the NETCON processor SET BOOTINFO command to change the handler or other boot 
i nf ormat ion. 

In online mode, the user is prompted to enter the information. As each item is prompted 
for, its current value is listed. 

The NETCON processor SET command con also be used to change a number of boot-time 
control parameters, general handler parameters, ASYNC-spec i f i c handler parameters, FEI 
handler parameters, and node administrator parameters. These parameters are all 
described in the SET Command Parameters table in the NETCON section of the System 
Support Reference Manual. 
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Module 6-1 

Introduction to Response and Throughput Tuning Tools 



This module introduces the reoder to vorious tools contained in the CP-6 system thot are 
used to obtain the maximum performance from o CP-6 system. System tuning techniques 
differ depending on how the CP-6 installation has been configured and the nature of the 
inefficiencies the tuning is meant to correct. But, the basic approach for use of the 
tools introduced in this section is always the same: the recommended CP-6 system tuning 
approach involves establishing a baseline of performance for a particular CP-6 
installation, and then recognizing deviations from this baseline. 

Once the baseline is established, the deviations need to be examined more closely: 
first, determining the type of problem which has presented itself; then, focusing even 
more closely in order to determine the cause, and thus the remedy, for the deviation. 
Occasionally the detecting of problems Is not quite so analytical, and requires 
vigilance and intuition to ferret out the cause. 

This module: 

o categorizes the kinds of system performance problems that con arise and 

o identifies in a general way procedures and tools available for detecting these 
problems. 

Module 6-2 is an example of how system statistics used in analyzing system performance 
problems can be gathered. Module 6-3 is a more detailed examination of how CP-6 
processors can be used to tune a system. 

There are several aspects to performance of a CP-6 system. Each aspect may exhibit 
itself OS a different type of problem, even though the problems may superficially appear 
to be the some. It is very important to identify the particular type of problem, in 
order to administer the proper corrective action. The following aspects of performance 
will be examined in this Introduction: 

o Responsiveness 

o Throughput 

o Memory utilization 

o Input/output throughput 

o FEP throughput 

As a general technique it is recommended that most CP-6 installations constantly run 
STATS as a batch or ghost job to keep a log of system performance activity. Module 6-2 
contains an example of how to run STATS as a ghost job. If a STATS log of system 
performonce activity is maintained, STATS con be used to onolyze the normal operating 
profile of the installation. This technique can also be used to assist in predicting 
the need for additional equipment. 

Given that STATS is being used to analyze the normal operating profile of an 
installation, the next step is to identify the existence of problems. Basically, there 
are two ways to do this. The first and recommended approach is to regularly watch the 
statistics being gathered to detect anomalies. The second, and generally less 
satisfactory, is to wait for complaints from the user of the system. 
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Once a problem has been identified, the next step is to classify the problem into one of 
the five areas mentioned above. For each type of problem, the next step is to use the 
tools to focus in on the particular problem, solve the most severe problem, and then 
re— examine the situation to see if a serious problem still exists. 

Ways to recognize each of the types of problems are discussed below. The discussions 
which follow all assume that a system is adequately configured ond hos experienced 
adequate performance. The techniques given ore intended to Identify changes in 
performonce characteristics in a system and to assist in obtaining the maximum from a 
CPS system. 



Responsiveness 

CP— 6 responsiveness performance can be divided Into three areas: time-shoring 
responsiveness, batch responsiveness, and transaction processing responsiveness. 



Trrie-sharing Responsiveness 

Time-sharing responsiveness ("Gee, the system seems to be responding slowly today") can 
be divided into three categories: 

o Host response 

o FEP saturation 

o Input/output bottleneck 

This section examines Host response problems. If a time-sharing responsiveness problem 
is not related to host response, then it is related to either FEP saturation or on 
input/output bottleneck. These aspects of performance are discussed as separate topics, 
be I ow . 

A host response problem manifests itself in one of two ways: slow response to trivial 
tasks, and slow response to more substantial compute-bound tasks. The response time to 
trivial tasks is the response time printed by the STATS processor, and problems of this 
type con be diagnosed directly from STATS. If this volue is not in a desirable range, 
it can be affected by adjusting the various QUAN, QMIN, and PRIO values using the 
CONTROL processor (see Module S-3). 

The response time to more substantial tasks is reflected in the ETMF (Elapsed Time 
Multiplication Factor) figure as reported by STATS. Abnormotly high ETMF values signify 
throughput problems which are discussed below. 



TP Responsiveness 

This class of problems can be due to Host transaction bottleneck, FEP saturation, or an 
Input/output bottleneck on the files or database in question. 

If o number of transactions ore not queuing up in the host for processing, then the 
problem must be an FEP saturation problem. The FPL programs should be examined for 
inefficient code. 

If the problem is not in the FEP, the problem may be caused by an input/output 
bottleneck contention for TPAPs or a throughput problem. Input/output bottleneck and 
throughput problems ore discussed in a separate topic, below. If the problem is due to 
contention for TPAPs, the transaction load should be analyzed carefully, and the most 
heavily used TPAPs should be considered for PERM status. (Refer to the publication CP-6 
TP Administrator Guide (CE50) for more information on TPAPs and PERM status.) 
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Batch Responsiveness 



Batch responsiveness is basically batch turnaround. The CONTROL processor can be used 
for batch turnaround problems to examine the particular definitions and the number of 
jobs running in each partition. Consideration should be given to establishing express 
partitions for fast turnoround of jobs with limited resource requirements. 



Throughput 

This section is concerned with CPU utilization problems and CPU users that create such 
problems. Generally, a CPU throughput problem is signalled by anomalously high ETMF. 
The high ETMF is usually due to one or more heavily used programs that are somewhat 
inefficient. To proceed further in this kind of problem analysis, the heaviest user of 
CPU time must be identified. The program ST.X(H) is the most useful tool for this 
purpose. ST.X(H) will take a 30-second snapshot of the system, and report the top six 
users of CPU time, memory, and input/output. 

Having identified the suspects, the next step is to determine whether the problem is an 
execution time or service time problem. The easiest way to make this determination is 
with ST.X (sysid). which will report the usage of a particular user of execution and 
service time. 

If it is determined that the throughput problem is a service time problem with a 
particular user, the best way to proceed is to use the MOUSE feature of STATS, reporting 
on the user in question. MOUSE provides a report of alt of the monitor services used, 
along with various statistics about the monitor services. (Refer to the CP-6 System 
Support Reference (CE41) for more information on the MOUSE feature of the STATS 
processor.) The program can then be analyzed to determine if it is doing unnecessary or 
inefficient operations. 

If it is determined that the throughput problem is an execution time problem, the best 
way to proceed is to use PMON.X to determine the execution time profile for the program. 

Usually, these steps will be enough to locate the problem so that the inefficient code 
can be eliminated without further difficulty. After having eliminated the principal 
offenders, the program should be re-examined for further problems. 

Frequently, a program will have a problem with both service and execution time, in which 
case both of the just described techniques should be used. 



Memory Ut i I izat ion 

If the problem appears to be that more memory is being used to support a system load 
than should be necessary, the following approaches should be used. 

First, an overall global picture of memory utilization should be obtained. The STATS 
processor RESOURCE display provides this information. As a result of this information, 
some adjustments to TIGR and CONTROL parameters may be desirable to reduce certain 
memory usages. (See Module 6-3 for an example of a STATS processor RESOURCE display and 
for more discussion of tuning a system using these parameters.) 

Then, the following steps should be performed: 

o The memory used by users of the system should be examined carefully. It may be 

necessary to constrain the memory available to online users, thus forcing jobs which 
use more memory into batch. 

o ST.X(H) should be used to examine the users using the most memory end ST.X(M) should 
be used to examine the profile of all user's memory. 
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o If there are applications using large amounts of memory, they should be exomined in 
more detail, especially if they are typically in use by multiple users. Remember 
that procedure is usually shared, but that data is not. 

o The next step is to examine the LINK mop of the user in question to identify the 
offending modules within the run unit. 

o Then the data map of the offending modules can be examined for extraneous doto 
usage. 



Input /Output Bottlenecks 

The STATS input/output display con be used to examine the load on various devices to 
determine if a system is experiencing on input/output bottleneck problem. If such o 
problem is detected, the next step is to determine if the problem is user-associated or 

conf i gurat i on-assoc i ated . 

ST.X(H) con be used to list the top six input/output users. If there are some 
standouts, there may well be inefficiency in the programs. The MOUSE feature of the 
STATS processor can be used to further identify the source of excessive input/output. 

If there ore no clear excessive input/output users, the bottleneck may be due to an 
imbalance among packs. Consideration should be given to moving heavily— used occounts to 
lightly-used packsets, or to splitting heavily-used packsets among several devices. 

FEP Bottleneck 

If on FEP bottleneck is suspected, the short form of the STATS processor FEP display can 
be used to determine the load on all FEPs. (Refer to Module 6-3 for on example of a FEP 
display.) Any FEP for which the utilization approaches 100% will be a probable cause of 
a bottleneck. Such an FEP should be examined more closely using the long form of the 
STATS processor FEP display to get a detailed breakdown of usage to determine the cause 
of the overload. Then, consideration should be given to moving lines in order to 
balance loads among FEPs. 



122 



FEP Bottleneck 
Module 6-1 



CES0— 00 



Module 6-2 

Collecting CP-6 Statistics 



To determine if o CP-6 system is meeting its goals and objectives, the system manager 
must measure system performance. CP-6 system performance is measured using the STATS 
processor (described fully in the CP-6 System Support Reference Manual (CE41)) to 
collect statistics on how the system is operating. 

The statistics that are collected by STATS are used for several purposes. The 
statistics are used: 

o To determine if the CP-6 system is meeting its goals and objectives defined in terms 
of STATS items. 

o When modifying the operation of the CP-6 system. 

o For long-term system planning. As illustrated in the example in this module, long 
term system planning can be automated if a synopsis of daily STATS data reduction is 
kept on a data file. 

All of these uses of statistics require that STATS data files be built. 

The STATS processor can be run in online, batch, or ghost mode. When collecting 
statistics for long-term system tuning and planning, STATS Is usually run continuously 
in the ghost mode because: 

o STATS requires fewer resources in the ghost mode: A terminal or a PEP port is not 
required and a batch partition is not required. 

o The system manager can ensure that STATS is started whenever the system is booted, 
by putting commands in the GOOSE-EGG file (described below). 

Since the collection of system statistics requires some system resources, use of STATS 
commands needs to be planned to minimize the resources required, and to ensure 
collection of sufficient data so that the statistics are meaningful. 

The CPU resource requirement to collect the system statistics is negligible. Host and 
FEP statistics can be collected for an entire 24-hour period and use less than 10 
minutes of CPU time. 

The memory resource requirement for the STATS processor to log the host and FEP 
statistics is less than 128KW. The amount of memory actually required by STATS is 
dependent upon the configuration of the system and the statistics that are logged. 

The disk space resource requirement for coilectlon of the statistics is dependent upon 
the system configuration, the statistics that are logged, and the frequency with which 
the statistics are logged. 

The interval that is used to log the statistics to the file is chosen to keep the CPU 
resource requirement very low, to keep the disk space requirement reasonable, and to 
collect sufficient data to moke the statistics meaningful. The interval is generally 
chosen to be 15 to 30 minute during the periods of high usage. A larger interval can be 
used during periods of light usage (e.g., a 120 minute during third shift or during a 
weekend) . 
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To ease the monogement of the omount of disk space used in the collection of statistics, 
a new file can be created every doy. Daily file creation allows: 

o Batch jobs to be scheduled to do the STATS data reductions. 

o riles to be moved from the current disk to another disk or tape for long-term 
storage in a timely manner. 

The statistics files con be moved to long-term storage on either a daily, weekly, or 
monthly basis. Once data reductions are performed end the files are moved to long-term 
storage, the files can be deleted from the current disk. The frequency with which files 
ore moved to long-term storage regulates the total amount of disk space used for the 
collection of system statistics. 

This module describes how to: 

o Create a ghost STATS user. 

o Create on XEQ file to gather statistics and perform data reduction on the 
Stat ist ics. 

o Ensure statistics gathering by using the GOOSE processor. 



Creating a Ghost STATS User 

The process of running STATS in the ghost mode to collect statistics is started by 
choosing a user id for the ghost user. This user id can be an existing user id or a 
special user id that is created for this purpose. In either cose, the user id must be 
authorized with the appropriate resources, access modes, and permissions to run STATS. 
In particular, the user id must be authorized for access in the ghost mode, must have 
sufficient file space to save the STATS files, must have sufficient memory to run STATS, 
and must have the PM PRIV to run STATS. The following figure is an example of how a 
special user id would be created to run STATS in the ghost mode. 



I SUPER 

cp-6 SUPER cee 

CMD*CREATE : STATS. STATISTICS FROM DEFAULT 
OPT* ACCESS B-YES. 0-YES, G-YES, TP-NO 
OPT»HSET « DP#SYS 
OPT^FACCOUNT 

suB*6R-i5eee, nolist-?, default backup, no acup 

SUB* 

0PT*MEM0RY MAX B-256, 0-256, G-256 
0PT*MEM0RY DEF B-128, 0-128. G-128 
0PT»PASS1W0RD « PASSWORD 
OPT ♦PR IV 

SUB*PM B-YES. O-YES, G-YES. TP-NO 
SUBTEND 

OPT ♦SETUP G - I XEQ STATS.XEQ 

OPT^END 

CMD^END 



Figure 6. Sample STATS User ID Creation 
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In the axompte: 



o The user id is authorized to run in botch, online, or ghost modes. The ghost mode 
con be used to collect the statistics; the botch and online modes con be used to do 
data reductions on the statistics. 

o A file management account is created on DP|SYS to hold the STATS files. DPfSYS is 
chosen as the home packset because that pockset is always mounted when the system is 
booted. The STATS ghost requires that the home packset be mounted when initiated 
because on XEQ file is used and because STATS will create statistics files. 

o The user id is given enough default memory to run the STATS processor. 

o The user id is given the PM privilege so that the STATS processor can be run. 

o The user id is given a setup command for the ghost mode. This setup command 
executes the STATS.XEQ. rSTATS file when the ghost is started. 



Creating an XEQ Command File 

The ghost STATS user is usually set up to execute on XEQ file. The XEQ file controls 
how the ghost STATS user collects the system statistics. In the previous user 
authorization, the XEQ file was specified in the SETUP option. The XEQ file name was 
STATS.XEQ. : STATS. If the SETUP option is used as shown, the STATS^XEQ. : STATS must be 
created. The following figure is on example of what that XEQ file could be like. The 
comments in the XEQ file describe how it functions. 

In this example: 

o The STATS commands to collect the system and FEP statistics ore embedded in the 
STATS_XEQ. : STATS XEQ file. These STATS commands ore put in o temporary star file 
(*STATS.COMMANDS) . They ore later used via on XEQ statement with the appropriate 
subst i tut ions. 

o The XEQ file submits one or two botch jobs to perform data reduction after 

collecting the statistics: data reduction of the statistics con be on automated 
port of statistics collection. 



DEFAULT PERIOD1_STOP$-e800. PERI0D1_INT$-6e 

DEFAULT PERIOD2_STOP$»1800. PERIOD2_INT$«30 

DEFAULT PERI0D3.ST0P$«2359. PERIOD3_INT$-60 

DEFAULT WEEKEND_ST0P$-2359 . WEEKEND_INT$-120 
II 

" This is an XEQ file that controls the execution of the 

" STATS ghost that collects system statistics. The STATS 

*' data is logged into a file whose name is of the form 

" STATSDATA_yymmdd where yymmdd is the dote as given by 

" the IBEX $DATE function. This file is created in the 

" current file directory (file management account). 
II 

The DEFAULT substitution variables PERIODn_STOP$ and 

" PERIODn_INT$ specify the stop time and interval size 

" for o period of every weekday. The start time for 

" PERI0D1 is 0000. The start time for all other periods 

" is the stop time of the previous period. The stop 

" time, specified using a 24-hour clock, must be specified 

" OS four decimal digits (with leading zeroes as necessary). 



Figure 7. STATS.XEQ: Sample STATS XEQ File (cont. next page) 
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The DErAULT substitution variables WEEKEND.STOP$ and 
WEEKENO_INT$ specify the stop time and interval size 
for the weekend. The start time for the interval is 
the STOP time of the lost period of the lost weekday 
(i.e., 2359). The stop time for the intervol must be 2359. 

Additional intervals can be added to the weekday and/or 
weekend by adding the appropriate DEFAULT substitution 
variables, command variables, and the appropriate IBEX 
commands to this XEQ file. 

This command file will not function correctly for 
collecting STATS data on a noncont i nuous basis. 
That is, the first period of the weekday/weekend must 
start at 0000 and the lost period of the weekday/weekend 
must end at 2359. 

WARNING: If the length of a period is not an even 
multiple of the interval, the switching of interval 
size will not occur at the specified start/stop times. 



Move all DEFAULT and SUBSTITUTION parameters into command 
variables. The delete all DEFAULT parameters. 
LET PERI0D1_ST0P = PERI0D1_ST0P$ , PERI0D1_INT = PERI0D1_INT$ 

LET PERI0D2_ST0P « PERI002_ST0P$ . PER I 002^1 NT = PERI0D2_INT$ 

LET PERI0D3_ST0P = PERI0D3_ST0P$, PERI0D3.INT - PERI0D3.INT$ 
LET WEEKEND.STOP - WEEKEND_ST0P$ , WEEKEND.INT - WEEKEND.INT$ 

DEFAULT DELETE 

II 

BUILD: Build command file, 

II 

Build the STATS command file. XEQ substitutions will 
" supply the appropriate values. 

IF $FID_EXIST ( •♦STATS_COMMANDS' ) THEN DELETE ♦STATS_COMMANDS 

EDIT 

BUILD ♦STATS.COMMANOS 
$STATS 

MESSAGE STATS collecting statistics using INT$ minute intervals 

FILE FILES 

INT INT$ 

DI NONE 

LOG PMDAT. FEP 

GO N TIMES 

END 

lEOD '* Terminate EDIT file data. 

SE; CL1,1; /$/S/l/ " Substitute ! for $ in STATS 

" command, so it will execute. 

END Terminate EDIT processor. 

I" 

IBEGIN: ** Beginning of iterative loop. 

I" 

I '* Get current date, time, and day of the week. Also calculate 
r* the current time as minutes since the beginning of the day. 
I LET DATE - $DATE 

I LET TIME » $TIME 
I LET DAY - $DAY 

I LET NOW - TIME / 100 ♦ 60 + fSUBSTR ( TIME. 2, 2 ) 

!" 

{WEEKEND: " Weekend decision. 

I" 



Figure 7. STATS.XEQ: Sample STATS XEQ File (cont. next page) 
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If this is not Saturday or Sundoy, go to the weekday decision. 
Otherwise, set the interval size and stop time based upon 
the weekend parameters. 
IF DAY 'SAT* t DAY — « 'SUN* THEN GOTO WEEKDAY 

LET INT » WEEKEND^INT 

LET START « 'OOee' 
LET STOP « WEEKEND.STOP 
GOTO CALCULATE 



! WEEKDAY: 



Weekday decision. 



PERI0D1 
IF 
LET 
LET 
LET 
GOTO 
PERI0D2: 
IF 
LET 
LET 
LET 
GOTO 
PERI0D3: 
LET 
LET 
LET 



Determine which period of the day this is. Then set 
the interval size and stop time based upon period of 
the day. 



THEN GOTO PERI0D2 



THEN GOTO PERI0D3 



! 
I 
I 
! 
I 
I 
I 
! 
! 
I 
! 
I 
! 
I 
! 
I 

!" 

! CALCULATE; 

I" 

1" Calculate the number of intervals to be done. Also 
generate the name of the file that is to be used. 

" WARNING: If the length of a period is not on even 

" multiple of the interval, the switching of interval 

" size will not occur at the specified stort/stop times. 

LET THEN - STOP / 100 ♦ 60 + $SUBSTR { STOP, 2. 2 ) 

LET N » ( THEN - NOW + INT - 1 ) / INT 

LET FILE- 'STATSDATA^' || DATE 

" Concatenate today's dote. 

EXECUTE: " Execute command file. 



TIME >= PERIODI^STOP 
INT - PERI0D1.INT 
START « '0000' 
STOP - PERIODI^STOP 
CALCULATE 

TIME >- PERI0D2«ST0P 
INT - PERI0D2_INT 
START « PERIODI^STOP 
STOP ■ PERI0D2_ST0P 
CALCULATE 

INT - PERI0D3_INT 
START « PERI0D2_ST0P 
STOP - PERI0D3.ST0P 



Calculat ions. 



r 

!' 
I' 

r 

!• 

I 
i 

! 

I 

! 

!' 
!' 
I' 
I 
I 
I 

I" 

I REDUCTION: 



" Execute the STATS command file with the appropriate 
" substitutions. 

XEQ ♦STATS^COMMANDS FILE$ - 'XFILE*. ; 

INT$ - %INT. ; 
N « XN 



Data reduction decision. 



I" 

I LET 
I LET 
I LET 
I LET 
I LET 
I LET 
I 



Submit the batch data reduction job for this 
Transfer variables from this XEQ file to the 



NAME - 'STATS 
YY « $SUBSTR 
MM = $SUBSTR 
DD = $SUBSTR 
MMDDYY - MM I I 
FROM - $SU6STR 
$SUBSTR 



• II DATE II 
DATE, 0. 2 ) 
DATE. 2. 2 ) 
DATE. 4. 2 ) 
V* II DD II 
( START. 0. 
( START, 2. 



period, 
botch job. 
START II II STOP 



/' 11 YY 



II 



Figure 7. STATS.XEQ: Sample STATS XEQ File (cont. next page) 
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1 ^Qi inCTD f CTr^ O 9 1 
I ^dUDO 1 It ^ O 1 Ur , Z , Z / 




iDAlUii oIAIo_KtUUvi iUN NAMt.^ ^ ^NAML , ; 




1 r 1 Lt.^ » 1 Lc. • ; 




t MML/UTT;^ = XMMUUTT , 












\ D6t0riiiin6 IT th© stop t ini6 of this int©rvQl is at 


me ena 


1 OT I nv coy* IT nox , Qo lo 009*'' ino n9XT inxorvai 




!" Otherwise, submit another batch data reduction job 


to 


! *' do the data reduction for the entire day. Then 90 


to 


r* begin the next Interval. 




II F STOP « 2359 THEN GOTO BEGIN 




ILET NAME « ' STATS. * || DATE || * 0000.2359' 




1 BATCH STATS.REDUCTION NAME$ = 'XNAME*. ; 




! FILES - 'XFILE' . ; 




1 MMDDYY$ « •XMMDOYY'. ; 




1 FROM$ = •00:00' . ; 




1 T0$ « •23:59', ; 




! SCHED$ » 'RERUN. ORDER' 




I GOTO BEGIN 





Figure 7. STATS.XEQ: Sample STATS XEQ File 



Gathering Statistics 

STATS commands are used to gather statistics. In the example. STATS commands in the XEQ 
star file are used to log all system and FEP statistics. In the collection of 
statistics for system tuning ond planning, all statistics are usually collected. Since 
oil statistics ore collected, the system manager has the ability to generate any or all 
stotistics displays to meet any unexpected requirements that might arise. 

The collected statistics are either displayed as is, or a data reduction is performed. 
A display of the collected statistics (i.e., a REPLAY) will print the statistics as they 
would hove been printed at the time they were being collected. Generally, statistics 
are replayed only if the system manager wishes to see how the system was operating 
during a period of particular interest. In this circumstance, a subset of the 
statistics for the time spon in question can be replayed on a terminal. 



STATS Data Reduction 

For system tuning and system ptonning, data reduction is generally performed on the 
collected stotistics. System tuning and planning decisions ore usually based on the 
results of data reductions performed in either online or batch mode. In online mode, 
the system monoger must use o terminal to perform doto reductions. In batch mode, the 
data reductions con be submitted automat i cot ly by the XEQ file thot controls the 
collection of the statistics. 
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Data reduction results need to be examined as they are produced. From these data 
reductions, the system manager con determine what is normal for the system. These data 
reductions will show the system manager if the CP-6 system is meeting its goals and 
objectives that ore defined in terms of STATS items. As the workload and system 
configuration change, the system manager will know from the data reductions when changes 
will have to be mode in the system tuning parameters. In addition, the examination of 
these data reductions may also reveal when the system configuration must be enlarged or 
upgraded to meet performance requirements. 

An example of a batch data reduction job is shown in the following figure. This is the 
botch job that would be submitted by the ST ATS.X EQ. : STATS XEQ file. 



I DEFAULT NAME$«STATS_REDUCT ION 

I DEFAULT WSN$»LOCAL. DEFER$-e:00, SCHED$»RERUN 

(DEFAULT TIME$»30:0e, MEM$=:'128 

! DEFAULT FP00LS$«31 

!JOB NAME»NAME$. WSN-WSN$, DEFER»DEFER$ , SCHED$ 

IRES TIME«TIME$, MEM-MEM$ 

I LIMIT FPOOLS«FPCX)LS$ 
! STATS 

FILE FILES 

SPAN FROM$. MMDDYY$ - T0$, MMDDYY$ 

HISTOGRAM RESPONSE(SNAP) . USER SI2E(SNAP). INTERACT I ON (SNAP) 

ALSO DI CPU, RESOURCES, DEVICES, CHANNELS. PROCESSOR, FEP SUM^RY 
GLOM 

STATISTICS ALL 
END 



Figure 8. STATS.R EDUCTION: Sample STATS Data Reduction Job 



In this example, selected STATS data reductions are performed. These data reductions 
provide a starting point for system tuning and planning in less than 20 pages of output. 
The smalt amount of output con be quickly read by the system manager. If some of these 
data reductions ore not useful, they can be removed from the data reduction commands. 
If other data reductions are required, they can be added to the data reduction commands. 

The reduction job example will function correctly under normal circumstances. If the 
system has an interruption (i.e.. ZAPI . DIEl, or SCREECH), the data reduction job will 
not function correctly because the STATS processor GLOM command cannot perform 
calculations for on interval during which a system interruption occurred. In this case, 
the system manager will have to manually perform the data reductions across the partial 
intervals. This procedure con be performed either at on online terminal or by 
submitting a batch job (i.e., the ST AT S_R EDUCTION job) with modified substitution 
parameters. 
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GOOSE commands 



After the user id has been created and the appropriate files have been built, the system 
manager can start the STATS collection ghost by using the GOOSE processor (described 
fuMy in the CP-6 System Support Reference Manual (CE41)). The following figure is an 
example of starting the STATS ghost. 



1 GOOSE 
Goose here 

: START : ST ATS, STAT I ST I OS. PASSWORD 
:END 



Figure 9. Starting STATS Ghost Immediately 



To ensure that the STATS ghost is started whenever the system is booted, the system 
manager can schedule the starting of the ghost in the GOOSE-EGG file, as shown in the 
fol lowing f igure. 



! GOOSE 
GOOSE HERE 
: UPDATE 
EDIT Cee here 
•AP 

1. eee start : stats, statistics, password at startup 

2. eee 

• END 

GOOSE.EGG updated 
Automatic scheduling updated 
:END 



Figure 16. Scheduling Start of STATS Ghost 



Using the specified command in the GOOSE-EGG file, the GOOSE processor will start the 
STATS ghost following every system boot or recovery. 



GOOSE commands 
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Module 6-3 

Using CP-6 Statistics 



The process of modifying the operation of o CP-6 system to meet specific goals and 
objectives is referred to os tuning the system. After CP-6 statistics have been 
collected and data reductions have been performed, the system manager can then use the 
dote reductions to do system tuning. The data reductions are used either individually 
or in combination with others to provide the data to moke tuning decisions. 

This module discusses how to use the various STATS displays for system tuning, and how 
to use TIGR, CONTROL. NETCON and SUPER processor parameters to modify the performance of 
a CP~6 system. The values that the system manager uses for these tuning parameters are 
based upon the current parameter values and upon the statistics gathered from the 
running CP-6 system. 

Note that to perform system tuning: 

o Several data reductions should be available. Usually, system tuning is aimed at 
providing the best CP-6 system performance for a normal workload. The normal 
workload is unique for each CP-6 system. The system manager determines the normal 
workload by examining the statistics continuously on a long-term basis. The system 
manager determines the normal workload for the CP-6 system and sets the tuning 
parameters accordingly. 

o System tuning parameters ore set in TIGR, CONTROL. NETCON, and SUPER. Changes in 
TIGR parameters are only effective after a reconfiguration boot has been performed. 
Changes in CONTROL and NETCON parameters are stored in the host and FEP monitor 
tables. Some of these changes become effective immediately. Other changes are 
effective only for new users as they log on. Changes in SUPER parameters are always 
effective the next time a user logs on. The description of the individual processor 
commands and, in some cases, the tuning parameters are documented in the CP-6 System 
Support Reference Manual (CE41 ) . That manual must be examined to determine when 
tuning parameter changes become effective. 

Normally, system tuning parameters are not changed for transient workload fluctuations. 
However, the system manager may find that the workload changes according to the time of 
day or day of the week. In this case, the system manager can establish separate tuning 
parameters for CONTROL (and, if appropriate, NETCON) for each of these periods. The 
system manager can then put commands in the GOOSE.EGG file that will cause the GOOSE 
processor to start a ghost user at selected times on selected days. (Refer to Module 
6-2.) This ghost user will execute XEQ files that will set the system tuning parameters 
in CONTROL and/or NETCON. 

If the tuning parameters are changed at selected times, the STATS collection XEQ file 
(e.g.. STATS.XEQ in Module 6-2) should be changed so that the periods coincide with the 
selected times. This allows STATS data reductions from each period to be used to odjust 
the tuning porameters for that period. In this situation, the system manager is 
actually tuning the CP-6 system for optimum performance during different workload 
condi t ions. 

Note too that the WASP tool in the X account con be used to perform online monitoring of 
many of the display items reported vio the STATS processor. 
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STATS CPU display and CPU Tuning 

The STATS processor CPU display provides an overall snapshot of what Is happening in the 
system. The STATS RESPONSE hlstogrorn is used as detailed information to help In setting 
the CPU tuning parameters. 



STATS CPU Display 

An exomple of a STATS CPU display is shown in the following figure. 
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Figure 11. STATS CPU Display 



When tuning a system, the system manger should use the STATS processor GLOM command to 
perform data reduction and examine the statistics in the snap column of the data 
reduction. These statistics ore the averages of the workload for the selected period. 
The statistics in the all column ore the overages of the workload since the system was 
lost booted. Since the all column may contain the statistics from several distinct 
periods* in most cases the all statistics are not used to moke system tuning decisions. 

The system manager should examine the percentages in the first eight lines of the left 
side of the display and the number of users in each mode to determine whether each CP->6 
access mode is getting the correct total percentage of the CPU for the period spanned by 
the stotistics. 

The following table defines the items in a STATS CPU display. 
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Table 8. STATS CPU Display Definitions 


Display Entry 


Def i ni t ion 


X mode execut ion 


The percentage of CPU time spent executing user code in 
each mode. The mode is specified as either botch, online, 
ghost, or TP. This percentage is directly chargeable to 
users in the form of CPU execution time. 


% mode service 


The percentage of CPU time spent executing monitor code to 
satisfy user monitor service requests. The mode is 
specified as batch, online, ghost, or TP. This percentage 
is directly chargeable to users in the form of CPU service 
t ime. 


% monitor execution 


The percentage of CPU time spent executing monitor code for 
internal monitor functions (e.g., scheduling, interrupt 
handling, etc.). This percentage of the CPU time is the 
monitor overhead. 


% I /Q wait 


The percentage of CPU time spent idle waiting for I/O 
operations to complete. If the system did not have to go 
into on idle state waiting for I/O to complete, this 
percentage will be zero. 


% resource wait 


The percentage of CPU time spent idle waiting for on 
internal monitor resource to become available. If the 
system did not have to go into an idle state waiting for an 
internal monitor resource to become available, this 
percentage will be zero. 


% I/O resource wait 


The percentage of CPU time spent idle waiting for I/O to 
complete or for an internal monitor resource to become 
available. If the system did not have to go into on idle 
state waiting for on I/O to complete or on internal monitor 
resource to become available, this percentage will be zero. 



CE60-eO 



STATS CPU Display 
Module 6-3 



133 



TobI e 8. STATS CPU D i sp I oy Def I n 1 1 i ons (cont . ) 



Display Entry Definition 



% true idle 

The percentage of CPU time that was spent idle with nothing 
to do. 



ETMF 

Execution time multiplication factor. This factor is 
multiplied times the required CPU time to give an estimate 
of how much elapsed time will be required to execute a 
task. For example, if a task requires 2 CPU minutes and 
the ETMF is 3» then the task will require approximately 6 
minutes of elapsed time to complete. 



90X response time 

The time in milliseconds between the receipt of an 
activation character (normally o carriage return) by the 
host and the start of processing for 90% of the activation 
characters received. The 90% response time is calculated 
only for online users. Note that this is not the response 
time from last character entered to first character 
received, and does not include delays in the FEP. 



I/O load factor 

This factor is the measure of the I/O load on the system. 
This foctor is the probability that an I/O request will be 
queued rather than executed immediately. This number is 
the average of the I/O load factors of all devices active 
during the interval . 



I of mode users 

The number of users on the system for each mode. The mode 
is specified as botch, online, ghost or TP. For a GO or 
REPLAY command, the number in the snap column is the number 
of users on the system in the respective mode at the end of 
the interval. The number in the all column is the average 
number of users on the system in the respective mode since 
the last system boot or recovery. For a GLOM command, each 
column is the average number of users on the system in the 
respective mode during the interval specified In each 
CO I iMin . 
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Tab 


e 8. STATS CPU Display Definitions (cont.) 


Display Entry 


Def i n 1 1 1 on 


I/Os per minute 


The number of I/O connects per minute to all lOM-connected 
controllers and system consoles. Each connect may contain 


Schedules per minute 


ThA niimKAr nf nn9«A« rsA r ifiiniit^ thmunh thA ^w^tiim 

scheduler. The number of schedules per minute is 
influenced by the number of I/Os per minute, the number of 
interactions per minute, and tuning parameters. 


Interactions per mtn 


The number of activation characters (e.g., corrioge return, 
line feed, etc.) received by the host per minute. 


Events per minute 


The number of scheduler events that occurred per minute. 


PMMEs per minute 


The number of monitor service requests per minute. Every 
monitor service request is a Privileged Master Mode Entry 
(PMME) CLIMB instruction. 


Avg. usee per PMME 


The average number of microseconds required to complete the 
monitor service request. 


Minutes in interval 


The number of minutes in the interval. The all column 
contains the number of minutes since the lost system boot 
or recovery. The snap columns contains the number of 
minutes in the interval of the INT or GLOM command. 
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STATS RESPONSE Hstogram 

The STATS RESPONSE histogrcwn provides detailed i nf orinat i on about the interactive 
response time for online users. The following figure is an example of the STATS 
RESPONSE histogram. 



STATS intervol from 08:08:36.94 to 15:39:12.98 



"Snap" histogram of interactive response time 
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Figure 12. STATS RESPONSE Histogrom 

The STATS RESPONSE histogram creates a histogram plot from the response time to every 
interaction that occurred during the requested interval. 

This histogram provides: 

o a detailed report of the 90% response time reported In the STATS CPU display. 

o a count and a percentage of the interactive response time for various time 
Interval 8. 



CPU Tuning 

If analysis of the STATS CPU display and the STATS RESPONSE histogram Indicates that one 
or more modes is receiving too much or too little of the CPU for the number of users in 
that mode, the system manager must change some of the TIGR. CONTROL, NETCON, and SUPER 
tuning porometers. 
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USERS TIGR Parameter 



One of the first tuning parameters to be established by the system manager is the 
moximum number of concurrent users ever to be allowed on the system. The maximum number 
of concurrent users allowed on the system is specified by the TIGR processor USERS 
parameter. The USERS parameter is an option on the TIGR processor MON command. The 
total number of users concurrently on the system in all of the access modes cannot 
exceed the number specified by the USERS parameter. Therefore, the system manager 
usually sets this parameter slightly greater than the total number of users that are 
expected on the system at any one time. 



LIMITU CONTROL Parameter 

After the TIGR processor USERS parameter has been set, the system manager still has the 
obility to reduce the total number of concurrent users on the system. The system 
manager can limit the total number of concurrent users on the system by using the 
CONTROL processor LIMITU parameter or the operator ON keyin. The total number of 
concurrent users specified by either of these methods must be less than or equal to the 
maximum number of concurrent users specified by the TIGR processor USERS parameter. 



UM CONTROL Parameter 

After the total number of concurrent users has been specified, the system manager must 
determine the maximum allowable number of users in each of the CP— 6 access modes. The 
maximum number of users in each mode is specified using the CONTROL processor UM 
parameter or various forms of the operator ON keyin. The sum of the maximum number of 
users in each mode (UM) con exceed the total number of concurrent users on the system 
(LIMITU). However, the system will not allow any user in any mode to log onto the 
system once the total number of concurrent users on the system has been reached. This 
con produce undesirable results for ghost and TP users. Therefore, the system manager 
must be very cautious when such a situation arises. Observing the following three 
guidelines wilt help avoid such undesirable results. 

1. The moximum number of ghost users should be larger than the maximum number of 
concurrent system- and installation-supplied ghosts. This ensures that ghost users 
are allowed to logon when they are initiated. Ghost users are usually Initiated by 
the system, by GOOSE commands in the GOOSE_EGG file, or by the START TP keyin. 
These types of activities generally should not foil because the maximum number of 
ghost users has been exceeded. 

2. The maximum number of online and TP users should be larger than the maximum number 
of concurrent online and TP users expected on the system. If the current number of 
online ond/or TP users reach the maximum number for that mode, the additional users 
in that mode that attempt to logon will receive a message that no more users in that 
mode ore being accepted. This con be very frustrating to a user sitting at a 
terminal. Only a lack of system resources (e.g.. memory) or specific system goals 
and objectives should cause this guideline to be ignored. 

3. The maximum number of botch users is chosen based upon the system goals and 
objectives. If the system goals and objectives specify that online ond/or TP users 
ore to receive good response time, the number of botch jobs must be limited to 
approximately two botch jobs per CPU. If the system goals and objectives specify 
that batch jobs ore of primary importance, a larger number of botch jobs can be run. 
However, dramatical ty increasing the number of botch jobs that are run concurrently 
actually increases the elapsed times of individual jobs and reduces total botch 
throughput. In other words, running three botch jobs with on ETMF of 1 will produce 
shorter elapsed times and more throughput than running six batch jobs with on ETMF 
of 3 or 4. 
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MAXACCT CONTROL Parameter 



The system manoger can use the MAXACCT CONTROL parameter to prevent a single user from 
monopolizing the botch user slots. This parameter specifies the number of jobs that 
will be run concurrently from the some account. For example, if the maximum number of 
botch users is 2» MAXACCT con be set to 1 to prevent a single user from running two 
botch jobs at the some time. Any user may submit several jobs, but in this cose, only 
one job from any one account will be run at one time. 



NPART CONTROL Parameter 

In the CP-6 system, the botch jobs to be run ore selected through the use of botch 
partitions. These botch partitions do not represent any real, physical resource. They 
ore used as a selection mechanism to choose the next batch job to run. When a botch job 
is actually in execution, it does not realty run in o partition. Rather, a botch job is 
associated with a batch partition during execution to control only the selection of 
other botch jobs for execution. Therefore, eoch of these batch partitions may hove more 
than one executing botch job associated with it. 

Each botch partition has several selection limits. If o botch job falls within all of 
the selection limits of a partition, the job is eligible to be selected from that 
partition. A batch job may be eligible to be selected from more than one partition. 
However, when placed in execution, it will be associated only with the one portition 
that it was selected from. 

The system manager selects the number of botch partitions that will be used to select 
batch jobs by specifying the CONTROL processor NPART parameter. The number of botch 
partitions (NPART) may exceed the number of concurrent botch jobs allowed on the system 
(UM(B)). Up to 16 botch partitions may be used to select botch jobs. The number of 
partitions used is dependent upon the selection criteria used to select botch jobs. The 
partitions that ore selected ore numbered from 1 through NPART. 



PLOCK CONTROL Parameter 

Even after NPART partitions are selected, the system manager can prevent the selection 
of botch jobs from one or more partitions by locking the partition. If a partition Is 
locked, no additional jobs con be selected for execution from that partition. If a 
partition is unlocked, jobs con be selected for execution from that partition. 

The system manager locks and unlocks portitions by specifying a value for the PLOCK 
CONTROL parameter. There is a PLOCK CONTROL parameter associated with each partition. 
Therefore, each partition con be locked or unlocked on on individual bosis. 



Partition Criteria CONTROL Parameters 

The selection criteria for eoch partition ore things such as CPU time, memory, real 
resources, pseudo resources, maximum number of jobs allowed to run in o partition, and 
maximum number of jobs from a single account allowed to run In a partition. The time, 
memory, and resources criteria hove minimum and maximum values for each partition. The 
maximum number of jobs and the maximum number of jobs for a single account only hove a 
maximum value for eoch partition. 

When selecting o job for execution, the ovoi loble partitions ore scanned from partition 
1 through partition NPART. If the first available partition contains o job that con be 
run, that job is placed in execution. If the first available partition does not contain 
0 job that con be run, the next partition is examined. If none of the partitions 
contain a job that can be run, no job is placed in execution. 
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The selection criteria for eoch partition must be established by the system manager. 
These selection criteria should be established to meet the system goals and objectives 
for batch jobs. For example, if an objective is to provide fast turn-around for small* 
short batch jobs» partition 1 can be set up to run only jobs that ask for 32KW of memory 
and less than 1 minute of CPU time. Partition 1 is used so that these small, short jobs 
will be considered before any other jobs. In addition, this partition con be set up to 
run OS many as 511 of these small jobs at once. The actual number of jobs run will then 
be controlled by the maximum number of batch jobs on the system (UM(B); and the number 
of batch jobs already running in other partitions. 

Other sets of criteria can be established for other partitions to accommodate other 
batch jobs. These criteria con include time, memory, real resources, pseudo resources, 
and maximum number of jobs. The number of sets of criteria helps to select the number 
of partitions (NPART) . 

Various CONTROL parameters are used to specify the partition criteria parameters. 
PMINTI and PMAXTI are used to specify the minimum and maximum time for each partition. 
PMINMM and PMAXMM ore used to specify the minimum and maximum memory for each partition. 
PMINres and PMAXres are used to specify the minimum and maximum resources (both real and 
pseudo) for each partition. PJMAX is used to specify the total number of jobs that con 
be in execution for each partition. PMAXACCT is used to specify the maximum number of 
jobs from a single account that can be executed for each partition. 



QMIN CONTROL Parameter 

After setting the limits on the number of users, the next CONTROL tuning parameter that 
should be established is QMIN. This parameter specifies the minimum time-slices that 
are given to users. 

The some or a different QMIN value con be established for each mode. If the percentage 
of CPU usage by each mode is acceptable, the same QMIN value can be used for each mode. 
Different QMIN values can be used to help change the percentage of CPU usage by each 
mode. In this cose, the different QMIN values ore based upon the online QMIN value. 
The value for QMIN for the online mode is chosen based upon the STATS histogram of the 
compute time between interactions. 

STATS INTERACTION Histogram 

The STATS INTERACTION histogram provides detailed information about the amount of 
compute time used between interactions. The following figure is an example of the STATS 
INTERACTION histogram. 
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STATS interval from 08:08:36.94 to 15:39:12.98 
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Figure 13. STATS INTERACTION Histogram 



The STATS INTERACTION histogram creates a histogram plot from the amount of CPU time 
each online user uses between each interaction. This histogram provides a count and a 
percentage of the compute time between interactions for various compute time intervals. 

Establishing the Online QMIN Value 

The online QMIN value should be set large enough so that trivial interactions ore 
completed within one QMIN. This ensures fast response to alt trivial interactions. The 
STATS INTERACTION histogram is used to determine what the trivial interactions ore for 
each particular system. The online QMIN value is then chosen after the trivial 
interaction compute time is determined from this histogram. 

For the example histogram, the QMIN value could be chosen anywhere from 20 (the minimum) 
to 130. The smaller value of QMIN will ensure fast response time to slightly less than 
26% (i.e.. 189S+4%4-4%) of the interactions. The longer compute time interactions will 
receive slower response time. The smaller QMIN value will also cause more trips through 
the system scheduler, and therefore, more system overhead in the form of monitor 
execut i on. 

The larger value of QMIN will ensure fast response time to opproximotely 49% (i.e., 
18%4-4%+4%+7%+7%+9%) of the interactions. All interactions with compute time up to the 
QMIN value will receive fast response time. The larger QMIN value will cause fewer 
trips through the system scheduler, and therefore, less system overhead in the form of 
monitor execution. However, the larger value of QMIN could also cause the 90% response 
time to increase. 

Values of QMIN larger than 130 would not bring substantial throughput or response time 
improvements for the system in the sample histogram. The percentages of interactions 
for the various compute times are decreasing above 130 milliseconds. 



QMIN CONTROL Parameter 
Module 6-3 



CE60-00 



The large number of interactions with greater than one second of compute time represent 
the compute-bound online users. Increasing QMIN to such large values will not actually 
help these compute-bound users. Such large QMIN values allow compute-bound users to 
monopolize the system. Such large values of QMIN will also dramatically increase the 
90% response time. 

The system manager should choose the online QMIN value from the range of values 
presented in this histogram. The QMIN value must be chosen to balance response time and 
throughput with the system goals and objectives. Usually, the QMIN value that provides 
the best response time will not provide the best throughput and vice versa. 

Establishing QMIN Values for Other Modes 

After the online QMIN value is established, the QMIN values for the other modes can be 
established. If the percentage of CPU usage by each mode is acceptable, the same QMIN 
value con be used for each mode. If the percentage of CPU usage by a mode is too large, 
a smaller QMIN value con be used for that mode. If the percentage of CPU usage by a 
mode is too small, o larger QMIN value con be used for that mode. However, the larger 
QMIN value can also hove the effect of increasing the 90% response time for the online 
users. Therefore, larger QMIN values must be used with caution. 

Normally, the botch QMIN value is set the same or smaller than the online QMIN value. 
This setting helps to prevent batch users from taking the CPU oway from online users. 
If the batch QMIN value is larger than the online value, online users may hove 
difficulties completing their tasks. For the ghost and TP modes, the QMIN value is 
usuolly set the some or larger than the online value. For ghost users, this setting 
helps to ensure that the system ghosts can accomplish their functions quickly and 
efficiently. For TP users, this setting helps to ensure that transactions are processed 
quickly. 



QUAN and PQUAN CONTROL and SUPER Parameters 

After setting the CONTROL processor QMIN parameter, the system manager must set the QUAN 
and PQUAN tuning parameters. These parameters specify the maximum time-slices that are 
given to users. The CONTROL processor QUAN parameter establishes the default tuning 
parameter for online, ghost, and TP users. The CONTROL processor PQUAN parameter 
establishes the default tuning parameter for botch users. The SUPER processor QUAN 
parameter establishes a specific tuning parameter for each mode for a user id. If a 
specific QUAN value has not been established for a user in a particular mode, the 
appropriate default CONTROL tuning parameter is used. 

The value chosen for the CONTROL processor QUAN parameter is based upon the QMIN values 
for online, ghost, and TP modes. The value for QUAN is usually a factor of 3 to 10 (or 
more) times the largest of these three QMIN values. The larger QUAN values tend to 
allow compute— bound users to dominate the system by locking out other compute-bound 
users. The smaller QUAN values tend to spread the CPU resource among the compute-bound 
users by causing schedules to occur more often. 

The value chosen for PQUAN is based upon the QMIN value for botch and the CONTROL 
processor QUAN parameter. The PQUAN value is used in conjunction with the QMIN 
parameter to regulate the percentage of CPU used by botch users. If PQUAN is smaller 
than QUAN, the botch CPU percentage will be reduced. If PQUAN is equal to QUAN, the 
botch users will be treated the some as online, ghost, and TP users. If PQUAN is 
greater than QUAN, the botch CPU percentage will be increased. 

A different PQUAN value con be specified for each botch partition. If a partition is 
running very short batch jobs, a PQUAN equal to or slightly greater than QUAN con be 
used to help process these jobs quickly. If o partition is running large, long botch 
jobs, a PQUAN value smaller than QUAN will help to ensure that the botch job does not 
lock out other (i.e., online, ghost, or TP) compute-bound users. 
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The SUPER processor QUAN parameter can be used to give a user or a group of users a 
special QUAN value for one or more access modes. These special QUAN values can be used 
to give o user or a group of users more or less of the CPU resource. If the special 
QUAN value is smaller than the default QUAN (or PQUAN) value, the user or group of users 
will receive less of the CPU compared to other users in that mode. If the special QUAN 
value is larger than the default QUAN (or PQUAN) value, the user or group of users will 
receive more of the CPU. 



IOTA CONTROL Parameter 

While the QMIN and QUAN parameters are used to control the relative total percentage of 
CPU utilization, the CONTROL processor IOTA parameter is used to control the relative 
I/O rotes of each of the modes. The volue of IOTA is used to reduce the current 
effective QMIN value for a user for each physical I/O. The larger the IOTA value* the 
slower the effective I/O rate for that mode. The smaller the IOTA value, the higher the 
effective I/O rate for that mode. 

The value for IOTA is chosen for each mode based upon the QMIN value and the desired 
effective I/O rate for that mode. A larger IOTA value can be used for the batch mode to 
prevent batch users from monopolizing system I/O. A smaller IOTA value can be used for 
TP users to allow the processing of transactions more rapidly despite database disk 
accesses. For example, with a QMIN value of 60 and an IOTA value of 10, a maximum of 6 
physical I/Os can be performed before the effective QMIN is reduced to zero and the user 
will be rescheduled. On the other hand, if the IOTA value is 4, a maximum of 15 
physical I/Os can be performed before the rescheduling will occur. 



PRIOB and PPRIO CONTROL Parameters and SUPER Parameters 

The QMIN, QUAN, PQUAN, and IOTA tuning parameters provide a very delicate tuning 
ability. The PRIOB and PPRIO tuning parameters provide a much coarser tuning ability. 
The PRIOB and PPRIO tuning parameters are used to specify the base execution priority. 
The base execution priority can shift dramatically the CPU and I/O resources between 
access modes and/or users. A higher base execution priority is given to a mode, user, 
or group of users only if their tasks are to be performed before anything else on the 
system. A lower base execution priority is given if the tasks are to be performed only 
after everything at a higher base execution priority has been given CPU resources. 

Since the base execution priorities have such a dramatic effect, they must be changed 
with caution. In particular, no mode, user, or group of users should be given a base 
execution priority such that they are able to reach an execution priority above the 
system ghost users. If this situation occurs, the system may hang. 

The system manager can give all access modes a default base execution priority of 2. 
This will allow the system manager to set the actual base priority of an access mode, 
user, or group of users below the system default base execution priority. Since the 
system default priority does not have to be changed to do this, all users do not have to 
be removed from the system. The new lower base execution priority will take effect as 
the users log onto the specified mode. 

The default base execution priority for online, ghost, and TP users is set using the 
CONTROL processor PRIOB parameter. The online and ghost default base execution 
priorities ore usually set to the some value. The TP default base execution priority Is 
either set the some as or higher than the online value. If the response time for TP 
users is a major system goal or objective, the TP default base execution priority can be 
set higher than the online value. For example, if the online value Is 2, the TP value 
con be set to 4. 



142 PRIOB ond PPRIO CONTROL Parameters and SUPER Parameters CE60--00 

Module 6-3 



The default base execution priority for botch users is set using the CONTROL processor 
PPRIO parameter. A default base execution priority con be established for each batch 
partition. A batch partition running short, small batch jobs con be given a default 
base execution priority equal to the online value. A batch partition running large, 
long batch jobs con be given a default base execution priority less than the online 
value if this does not violate the system goats and objectives. 

In general, no batch default base execution priority should be greater than the online 
value. If the batch value is greater, online users will encounter great difficulties in 
completing their online tasks. 

The SUPER processor PRIOB parameter can be used to give a user or a group of users a 
special base execution priority for one or more access modes. These special PRIOB 
volues con be used to give a user or group of users more or less of the CPU resource. 
If the special PRIOB value is smaller than the default PRIOB (or PPRIO) value, the user 
or group of users will receive less of the CPU than users with a greater base execution 
priority. If the special PRIOB value is larger than the default PRIOB (or PPRIO) value, 
the user or group of users will receive more of the CPU than users with a lower base 
execution priority. 



STATS RESOURCE Display for Resources and Resource Tuning 

The STATS RESOURCE display shows where and how much of various system resources are 
used. For this discussion, the STATS resource display is divided into two ports: 
monitor resources and memory utilization. 

STATS RESOURCE Display for ^4onitor Resources 

The following is an example of a STATS RESOURCE display of monitor resources. 



STATS interval from 08:08:36.94 to 15:39:12.98 



CP-6 monitor resource utilization 
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Figure 14. STATS RESOURCE Display of Monitor Resources 
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The first lines In this display show the current usage, minimum, overage, and maximum 
usage since the lost system boot, and the total number of various internal monitor 
resources. With the exception of the I/O cache entries, all resource usage is reported 
on 0 single line. The I/O cache entries item is expanded into a table that follows the 
single line resource usage reports. The items in the I/O cache port of the table are 
defined below in the section "I/O Cache Tuning". 



CE60-00 



STATS RESOURCE Display for Monitor Resources 
Module 6-3 



143 



Resource Tuning 



The following system tuning octions should be token for oil resources displayed except 
I/O cache entries. If the RESOURCE display shows that the maximum usage of a resource 
is the same as the total number of the resource in the system, the system manager must 
closely monitor the resource. If the RESOURCE display shows that the current and/or 
average usage of a resource is at or near the total number of the resource in the 
system, the system manager must increase the totol number of that resource in the 
system. If the RESOURCE display shows that the maximum usage of a resource never 
reaches the total number of the resource in the system, the system manager may 
cautiously decrease the total number of that resource in the system. 



DOLIST, ENQ, and QUEUE TI6R Parameters 

The total number of the resources displayed in the RESOURCE display (except the I/O 
cache entries) is controlled by entries on the MON card in the TIGR deck. The total 
number of o resource is increased by increasing the corresponding parameter via the MON 
command. The total number of lOQ and lOS resources are controlled by the parameters of 
the QUEUE option on the MON command. The total number of the Enqueue/Dequeue data 
blocks is controlled by the parameters of the ENQ option on the MON command. The total 
number of Scheduler Do-list entries is controlled by the parameter of the DOLIST option 
on the MON command. 

Since these resources are controlled by TIGR parometers and changes to TIGR porometers 
ore not effective until after o reconfiguration boot is performed, these TIGR parameters 
are usuoMy mode slightly larger than required by the system to allow some room for 
growth, which will eliminate having to moke TIGR changes and perform reconfiguration 
boots frequently. 



I/O CACHE Tuning 

The I/O cache provides a way to reduce the number of I/Os in the CP-6 system. The 
system manager con tune the caching system to the particular CP-6 environment. The 
system manager can control the amount of caching done, as well as the type of caching. 
The system manager can control: 

o the size of the I/O cache table (through the TIGR deck). 

o expire times, which determine which type of granules ore retained the longest. The 
expire times may be adjusted individually for each granule type as the system is 
running (through the CONTROL processor EXPTIME system parameter). 

o the update limit, which eliminates many of the writes to disk (through the CONTROL 
processor UPDLIMIT system parameter). 

As the caching system runs, it gathers statistics that indicate how welt the system is 
running, and provides information to help the system manager tune the system to the 
specific environment. These statistics are mode available through the STATS processor. 

When o CP-6 system is booted a set of default values for the I/O cache expire times, and 
cache table size is used. STATS can be used to tune these values, so the I/O cache is 
used more efficiently. 
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The I/O cache uses main memory to cache disk granuies. If CP-6 memory management needs 
memory, it may make a request to the I/O cache system for memory. The I/O cache system 
decides which memory to give to memory management based on the values for expire time. 
If the values for expire time are set too high, then memory management will have to make 
hundreds of colls to the I/O cache system to get the memory it needs. If the values for 
expire time are too low, then the I/O cache wilt give memory management more memory than 
it actually needs, and the extra memory will be left unused, when it could be used for 
caching granules. 



STATS I/O CACHE Displays 

The STATS processor DISPLAY RESOURCE and SUMMARIZE CACHE commands ore used to produce 
displays that can be used for tuning the coche. 

The SUMMARIZE CACHE displays looks as follows: 

Interval end IOC Trnc 
11:43:18.56 0 

The display indicates the number of truncs per minute. A trunc occurs each time the 
memory management system requests memory from the I/O cache system. A value of 0 
indicates that the I/O cache system is called less than once per minute for memory. 
High trunc values indicate that the I/O cache is not being used efficiently. 

The I/O cache octivity table in the STATS RESOURCE display is pictured below. 





STATS interval froni 


08:08:36.94 to 15:39 


:12.98 








I/O cache act i vi ty 


(act ions 


per minute) 










Attempted 


Hits 


Hits 


Percent 


At tempted 


Fai 1 ed 


Unused 




Gets 


UC-0 


UC>0 


Hits 


Puts 


Puts 


Poges 


MAD 


10 


10 


0 


99 


0 


0 


12 


{al 1 






111 


111 


0 


99 


0 


0 


11 


{snap 




PAD 


2 


2 


0 


95 


0 


0 


12 


|al 1 






19 


18 


0 


95 


1 


0 


15 


{snap 




GP 


33 


29 


4 


99 


0 


0 


15 


{all 






134 


119 


15 


99 


0 


0 


21 


{snap 




ro 


174 


170 


1 


98 


3 


0 


244 


{al 1 






460 


433 


6 


95 


22 


0 


169 


{ snap 




FIT 


207 


130 


3 


64 


74 


0 


164 


{al 1 






588 


453 


15 


79 


121 


0 


280 


{snap 




UL 


17 


17 


1 


98 


1 


0 


18 


{all 






75 


66 


7 


96 


6 


0 


36 


{snap 




INDEX 


74 


58 


8 


88 


13 


0 


83 


{al 1 






468 


346 


42 


82 


107 


0 


484 


{snap 




DATA 


331 


266 


19 


86 


71 


0 


697 


{al t 






2041 


1432 


72 


73 


706 


0 


2179 


{ snap 




REL 


0 


0 


0 


65 


0 


0 


0 


{al 1 






0 


0 


0 


0 


0 


0 


0 


{snap 




CONSEC 


40 


28 


0 


70 


36 


0 


2512 


{all 





Figure 15. STATS RESOURCE Display of I/O Cache Activity Table (cont. next page) 



CE60-00 STATS I/O CACHE Displays 145 

Module 6-3 



161 


98 


6 


59 


175 


13 


0 


0 


0 


14 


33 


0 


0 


0 


36 


902 


711 


35 


82 


210 


4094 


3071 


162 


78 


1173 



0 208 (snap 

ELSE 13 0 0 0 14 0 0 }at i 

0 0 I snap 

Total 902 _7n 35 82 210 0 3757 {all 

0 3403 (snap 



Figure 15. STATS RESOURCE Display of I/O Cache Activity Tobia 



The left column Indicates the types of granules that are being cached. (See the table 
on I/O cache granule types.) The Attempted Gets column contains the number of times an 
attempt was made to get an item from the cache. A Hit occurs when the attempt was 
successful. The Attempted Puts column contains the number of times an attempt was made 
to put an item into the cache; Failed Put is the number of times the attempt failed. 
The Unused Pages column contains the number of pages in the I/O cache that are currently 
not in use. 

The Failed Puts column is useful for determining if the size of the I/O cache table, as 
set by the TIGR command, was large enough. If any of the rows indicate non— zero values 
regularly, then the size of the cache should probably be doubled. 

The Unused Pages column, and the t runes information from the SUMMARIZE CACHE display are 
used for tuning the CONTROL processor EXPTIME parameter. Items that have a low number 
of unused pages should probably remain in the cache longer, and therefore have higher 
values for expire times. Items with a higher number of unused pages should probably 
have lower expire times. Evaluation starts with the item that has the highest number of 
unused pages. Typically, the DATA row will have over half of the unused pages in the 
cache. If the cache is tuned properly, the expire time for DATA items will be about 
half of the time between cache truncs. In this case, whenever the memory management 
requests memory from the I/O cache, about half of the I/O cache will be freed for use by 
memory management. 



Table 9. I/O Cache Granule Types 


Granule Types 


Descr i pt i on 


CONSEC 


Consecutive files, which contain data records(only) . 


DATA 


Data granules, which contain keyed file data. 


ELSE 


All other granules (including symbiont files and 
uni t record f i les) . 


FD 


File Directories, each of which contains a list of 
all files in on account. 


FIT 


File Information Table, containing access controls 
and other file specific information for oil files. 


GP 


Granule Pool, a list of free gronules on the packset. 


INDEX 


Index granules, which contain the record keys for 
keyed f 1 las. 


MAD 


Master Account Directory, a global list of all 
accounts on the systam. 
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Table 9. I/O Cache Granule Types (cont.) 


Granule Types 


Descr i pt i on 


PAD 


Pockset Account Directories, each of which contains 
a list of oil accounts in the pockset. 


REL 


Relative files, which contain fixed length data 
records (only). 


UL 


Upper level index, which contains pointers to 
index granules. 



For example, suppose during the system's peak load, the number of truncs per minute is 
about 50. This means that the I/O cache is truncated about once every 1.2 seconds. The 
system manager can set the value for the DATA expire time to about 60 (the value is in 
hundredths of a second) and use the Unused Memory column to set the remaining values. 
If the MAD row has about 1/100 the unused pages of the DATA row, the system manager can 
set the expire time for the MAD to about 6000. 

After the new values ore set, the cache should be monitored again. The new expire times 
will affect how often the cache will be truncated. This first guess may be too low, or 
too high. Eventually, a balance will be reached. Exact values for expire times will 
not be possible, since the I/O load on a system often varies depending on the time of 
day^ or day of the week. Two or three iterations of the above procedure will probably 
be sufficient. 



STATS RESOURCE Display for Memory and Memory Tuning 

The second part of the STATS RESOURCE display shows how system memory is used. The 
STATS RESOURCE display and the STATS USER SIZE histogram are used to set the resource 
memory utilization tuning parameters. 



STATS RESOURCE Display for Memory UtiSzation 

In the following example of a STATS RESOURCE display of memory utilization, note the 
zero-valued items. Zero-value items ore normally suppressed. They ore included here to 
ocquoint the reader with these possible display items. 
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Figure 16. STATS RESOURCE Display of Memory Utilization 



The items in this part of the STATS RESOURCE display are described in the following 
table. For a GLOM data reduction, this part of the RESOURCE display will show the 
average memory usage for various system functions. During operation, the total 
dedicated memory remains constant. The remaining memory categories ore changing very 
rapidly. 
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Table 10. STATS RESOURCE Memory Diaploy Definitiona 



Item Definition 



AARDVARK and RECOVERY 

Pages required for the boot processor (AARDVARK) and the 
automatic recovery processor (RECOVERY). 



XDELTA and monitor debug schema 

Pages required for the monitor debugger (XDELTA) and the 

debug schema used to debug the monitor. The size of the 

debug schema area may change by specifying different values 
to the FUNCTIONAL CODE GROUPS question at boot time. 



Monitor procedure and static data 

Pages required for the monitor executable procedure (i.e., 
PROC:%...) and static data (i.e.. DCL%. . .%STATIC) . 



Monitor context (JITs, MJITs, PPUT. page tables) 

Pages required for the monitor context area, which includes 
the monitor Job Information Table (JIT), House-keeping JIT 
HJIT), physical page use table (PPUT). and page tables 
PT). 



Monitor dynamic data segments 

Pages required for monitor dynamic segments, which Includes 
CPUs, LDCTs. ASAVE and ENQ. 



TIGR-built tables 

Pages required for tables built by TIGR at boot time. This 
includes the user table. I/O cache, device tables and 
outoshore tobies. 



Communications WSQs 

Pages used in communication with FEPs. These pages are 
controlled by the INQSZ and OUTQSZ parameters on the TIGR 
processor FEP command. 



Comgroup queue 

An areo for comgroup context. 
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Table 10. STATS RESOURCE Memory Dtsplqy Definitions (cont.) 



I tern Def i n i t i on 



Total pages held back for monitor use 

Pages reserved for CPUs, LDCTs, ASAVE, ENQ and steal able 
pages. These pages are affected by the CFU, DEVMAX» ENQ. 
and STEALPGS options on the TI6R processor MON command. 



Resident system ghosts 

Pages required for resident system ghosts. These are ghost 
users that perform part of the operating system's functions 
such OS ELF, PIG, SLUG, INSYM. and CUTSYM (and are referred 
to as the MING ghosts). 



Required processors (IBEX, DELTA, LOGON) 

Pages required for the IBEX, DELTA, and LOGON processors. 
These processors must be present for the system to 

f unct ion. 



All other special shared (resident) processors 

Pages required for all processors, shared libraries, 
alternate shored tibrories, and debuggers. These items are 
specified on the SPROC options on the TIGR processor MON 
command. 



Totol dedicated memory 

Total pages required by the monitor, its tables, ghosts, 
and processors. 



Aval lobte to users 

Pages available to users. This number is the difference 
between the total pages in the system and the total 
dedicated memory. 



Currently atlocoted to users 

Pages that ore currently actually allocated to users. 
These pages cannot be shared. These pages plus the 
automatically shared run unit pages in use, plus the shared 
dato segments in use constitute oil user memory. 
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Tobia 10. STATS RESOURCE Memory Dtsploy Definitions (cont,) 

Item Definition 
Automot i CO I ly shored run units in use 



Pages of procedure of automatically shared run units that 
are currently being used by one or more users. 



Shared data segments in use 



Pages of shared data segments currently being used by one 
or more users. 



Free pages 

Pages in the system not currently used for any purpose. 



Automatically shared run units not in use 



Pages of the procedure of automatically shared run units 
that ore not being used by any user. The pages are 
candidates to be used for other purposes If the free pages 
are exhausted. 



I/O cache pages (Use Count»0) 

I/O cache pages not currently being used. 



Total pages currently available 



Pages on the system that ore currently available for use. 
This number is the sum of the free pages and pages for the 
automatically shared run units not In use. 



Suspected bad physical pages 

Pages that have been marked as suspect by TOLTS. 

Physical pages being tested 

Pages that ore currently being tested by TOLTS. 

Confirmed bod physical poges 

Pages that have been partitioned by SYSCON. 
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Toble 10. STATS RESOltfK^E Memory Disploy Definitions (cont.) 



Item Definition 



I/O coche pages 

Totol I/O coche pages, both used and unused. 



Number of pages not accounted for 

Pages that cannot be currently accounted for. Because of 
the dynamic page usage of CP— 6, pages ore constantly being 
assigned to new functions or usages. This number reflects 
the number of pages that are currently in a status that 
STATS is unaware of. 



Totol physical poges in system 

Total pages in the system. This is the system memory size 
OS found by AARDVARK at the lost system boot or recovery. 



STATS USER SIZE Hstogram 

The STATS USER SIZE HISTOGRAM provides detailed information about the memory sizes of 
oil users. It creates o histogram plot from the memory sizes of all users in the 
system. This histogram provides: 

o a detailed report of the memory currently assigned to users in the STATS RESOURCE 
display for memory. 

o a count and a percentage of the memory sizes for various memory size ranges. 
The following figure is an example of a STATS USER SIZE histogram. 
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"Snap" histogram of user memory sizes 
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Figure 17. STATS USER SIZE Histogram 



Memory Tuning 

The CONTROL processor AUTOSHARE and MAXMM parameters are used in memory tuning. 



AUTOSHARE CONTROL Parameter 

The CP'-6 system was designed and developed to share a single copy of the procedure area 
among all users of a program. However, the system manager can control whether or not 
the procedure area for run units is shared. The sharing of the procedure area in run 
units is controlled by the CONTROL parameter AUTOSHARE. Either none, some, or all 
procedure areas can be shared. The default is that some procedure areas are shared 
based upon the LINK options in the run unit. 

Use of the NONE option is not advised unless absolutely required by system goals and 
objectives. Use of this option will dramatically increase memory requirements, and will 
also cause a degradation in system performance. 
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MAXMM CONTROL Parameter 



Because of the extensive use of memory sharing, the default maximum memory for each mode 
is greater than the total physical memory on the system. However, the system monager 
can specify the total omount of memory available to each mode. The total amount of 
memory for each mode is specified using the CONTROL parameter MAXMM. In most normal 
system operations, the system manager wilt not need to change the default setting of 
these porometers. 

Limiting the total amount of memory for online, ghost, and TP users can have undesirable 
results. Ghost and TP users may not be able to recover from a memory limit exceeded 
error. Online users may acquire memory to do their tasks and then not release the extra 
memory when no longer required, which can lead to reduced memory utilization on the 
system. 

The total amount of memory for batch users can be limited. Since batch jobs must 
specify the maximum amount of memory they will use on their RESOURCE command, batch jobs 
will not be aborted because a total memory limit is exceeded. However, batch jobs will 
still be aborted if their individual memory limit is exceeded. 

The total amount of memory for batch users can be limited to control the batch memory 
usage regardless of hom many batch jobs are executing. For example, total botch memory 
could be restricted to 1024 pages (i.e., 1024WW). This means that if 768KW of batch 
memory is already in use, a job requiring more than 256KW of memory will not be eligible 
to begin execution. However, a job requiring 256tOM or less memory will be eligible to 
begin execution. 



STATS DEVICE Display and Overload Problems 

The STATS DEVICE display provides detailed information about input/output activity on 
IOM>connected consoles, controllers, ond devices connected to lOM controllers. 



STATS DEVICE Display 

The following is an example of port of a STATS DEVICE display. 
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Figure 18. STATS DEVICE Display (cont. next page) 
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Figure 18. STATS DEVICE Display 
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The following table describes the heodings in this STATS DEVICE display. For a GLOM 
data reduction, there will be an all and a snap line for each device. The all line 
shows the average device activity since the last system boot or recovery. The snap tine 
shows the average device activity for the requested interval. 



Table 11 . 


STATS DEVICE and CHANNEL Display Definitions 


Heading 


Def ini t ion 


1 of connects 


The number of connects to the controller, device, or 
channel. A connect is performed at the beginning of an 
input/output request. A connect may contain more than one 
input/output operation. 


connects per min. 


The number of connects per minute to the controller, 
device, or channel; that is the number of connects divided 
by the number of minutes in the interval. 


X idle 


The percentage of time the controller, device, or channel 
is idle. Idle means no input/output is in progress and no 
input/output is woittng. For controllers this value is 
always 100X. 


% wai t 


The percentage of time the controller, device, or channel 
is waiting. Waiting means no input/output Is in progress, 
and one or more input/output requests ore woiting but 
cannot be started because no lOM channel or controller slot 
is available. For controllers and channels, this value is 
always OX. 


X busy 


The percentage of time the controller, device, or channel 
is busy. Busy means input/output is in progress and no 
other input/output request is waiting. For control lers» 
this value is olwoys 0X. 
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Table 11 . 


STATS DEVICE and CHANNEL Display Definitions (cont . ) 


Head i ng 


Def i n i t i on 


% backlog 


The percentage of time the controller, device* or channel 
input/output is back logged. Backlog means one input/output 
is in progress and one or more input/output requests ore 
waiting. For controllers and channels, this volue is 
always 0X. 


load factor 


The percentage of time an input/output request for a 
controller, device, or channel will be queued instead of 
initiated immediately. This percentage is calculated as 
LOAD FACTOR - 10eX * ( wait + backlog ) / ( 100 - idle ). 
For controllers and channels, this value is always 0%. 



HancBng Overtoad Problems 

The sum of the idle, wait, busy, and backlog percentages should be 100%. If the sum is 
not exactly 100%, the problem is usually caused by rounding errors. 

The load factor con be converted from a percentage to a probability by dividing by 100. 
Then the load factor can be viewed as the probability that on input/output request will 
be queued instead of initiated immediately. 

The load factor can be used to determine if a disk spindle is being overloaded. If this 
figure is greater than 50% for any individual disk spindle, there is a substantial 
amount of contention for access to thot spindle. Users attempting to access that 
spindle will suffer limited input/output throughput. If this figure is greater than 75% 
for any individual disk spindle, the throughput limitations will be very severe. 

There are no system tuning parometers than can correct a disk spindle overloading 
problem. Rather, the system manager may move some heavily used accounts to another 
packset. The system manager determines the files and accounts to be moved by using the 
ANLZ processor CFU command when the overloaded situation is occurring on the disk 
spindle. The system manager then uses PIG and/or EFT to move the heavily used occount 
to another packset on another disk spindle. 

If the account cannot be moved to another packset (e.g., the accounts must reside on 
DPfSYS) , the system manager may change the physical organization of the packset. This 
is done by using PIG either to EXTEND the existing packset or to SCRATCH and then BUILD 
a new packset spread across additional spindles. By spreading a packset across 
additional spindles, greater input/output throughput for the packset can be realized 
through the additional disk access mechanisms. 
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While extending or building of a pockset across multiple spindles provides additional 
input/output throughput for the packset, it also causes o reduced reliability for the 
pockset. If one volume of a multi volume packset cannot be mounted* the entire pockset 
is unavailable for use. Therefore, the additional input/output throughput is gained for 
0 packset at the cost of reduced reliability for the packset. The system manager must 
use the system goals and objectives to determine whether the disk overloading problem 
should be solved by building o multivoiume packset on multiple spindles. 

STATS CHANNEL Display and Channel Loading Problems 

The STATS CHANNEL display provides detailed information about input/output activity on 
alt lOM channels connected to consoles and controllers. 

STATS Channel Display 

The following is on example of a STATS CHANNEL display. 
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Figure 19. STATS CHANNEL Display (cont. next page) 
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Figure 19. STATS CHANNEL Display 



The previous table describes the headings in this display. For a GLOM data reduction, 
there will be an all and a snap line for each channel. The ail line shows the average 
channel activity since the last system boot or recovery. The snap line shows the 
average channel activity for the requested interval. 



Handing Channel Loadng Problenns 

There are no system tuning parameters that can dromoticolly change the channel loading. 
Channel loading can be effectively changed by moving disk or tape devices to another 
subsystem. (Each subsystem is specified by a DISK or TAPE command in TIGR.) Channel 
loading can also be changed by adding additional physical and/or logical channels to 
cont rol I ers. 



STATS PROCESSOR Display and Processor Tuning 

The STATS PROCESSOR display provides detailed information about the CPU usage by shared 
processors (i.e., run units). 



STATS Processor Display 

The following is an example of a STATS PROCESSOR display. 
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Figure 20. STATS PROCESSOR Display 



The following table describes the headings in the STATS PROCESSOR display. For o GLOM 
data reduction, the all column shows the overage CPU usage since the lost system boot or 
recovery. The snap column shows the average CPU usage for each processor during the 
requested interval. 
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Toble 12. STATS PROCESSOR Display Definitions 



Heodi ng Def ini t ion 



Processor name 

The processor name is token from the name of the run unit. 
The account is not reported as part of the processor name. 
If run units with the some name ore run from separate 
accounts, there will be multiple entries with the some 
processor name. 



Type 

Specifies the type of the processor. The type is one of 
the f ol lowi ng: 

icp Interactive command program. This program executes 
in the command processor domain. 

idb Interactive debugger. This processor executes in 
the debugger domain. 

std standard run unit. This processor executes in the 
user domain. 



Users 

Specifies the number of users of the processor. For the GO 
or REPLAY commands, this is the number of users of the 
processor during the interval. For the GLOM command, this 
is the overage number of users of the processor during the 
i nterval . 



% exec 

Specifies the percentage of CPU time spent in execution in 
the processor for ol I users of the processor. For the snap 
column, this is the percentage of CPU execution time used 
by this processor during the interval. For the all column, 
this is the overage percentage of CPU execution time used 
by this processor since the lost system boot or recovery. 



% serv 

Specifies the percentage of CPU time spent in processing 
monitor service requests for this processor for all users 
of the processor. For the snap column, this is the 
percentage of CPU service time used by this processor 
during the interval. For the all column, this is the 
overage percentage of CPU service time used by this 
processor since the lost system boot or recovery. 
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Processor Tuning 



The STATS PROCESSOR display shows the percentage of CPU time that is being used by 
various shared run units for all users of the run units. The shared run units that ore 
reported upon ore the most used shared run units. The system manager can use this 
display in several ways. 

This display con be used to ensure that multiple copies of the some program are not used 
from separate accounts. The system manager should attempt to collect all commonly used 
programs and place them in one or more library accounts. If commonly used programs are 
used from common accounts, memory requirements will be decreased and system performance 
and throughput will be increased. 

This display con o I so be used to examine those installation-supplied run units that are 
consuming large amounts of CPU time. In this case, the system manager should examine 
the efficiency of the installation-supplied run units. The system manager can do this 
by using the PMON and PMOISP tools in the X account. If heavily used 
installation-supplied run units have sections where efficiency can be improved, system 
performance and throughput can be increased by improving these programs. 

This display can also be used to control the maximum number of concurrent users of a 
processor. If the amount of CPU usage of a processor violates the system goals and 
objectives, the system manager con control the maximum number of concurrent users of a 
processor. This control is started by creating a pseudo resource via the TIGR processor 
MON command. Then, the run unit is modified by CONTROL or by relinking with a LINK 
option to require the pseudo resource. The system manager can then use CONTROL to 
control the maximum number of the pseudo resource in each of the access modes. The 
system manager can use SUPER also to control which users are able to acquire the pseudo 
resource . 

This process means that the user must acquire a pseudo resource before running the 
progrom. In botch mode, the pseudo resource must be requested via the IBEX processor 
RESOURCE command. In the online mode, the user must acquire the resource by using the 
IBEX processor ACQUIRE or ORES commond. 

STATS FEP SUMMARY Display and FEP Tuning 

The STATS FEP SUMMARY display summarizes the performance of the FEP(s) on the system. 

STATS FB' Sunrvnary Display 

The following is on example of the STATS FEP SUMMARY display. 
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Figure 21. STATS FEP SUMMARY Disploy 



For the GLOM data reduction, these numbers ore the averages for the specified period. 
The system manager uses these number to set various FEP tuning parameters. The STATS 
processor FEP DATA or FEP EXTENDED commands can be used to create more detailed displays 
on FEP performance. 



Tuning FEPs 

Both NETCON and TIGR processor porometers can be used to support FEP tuning. 



BLOCK and UNBLOCK NETCON Parameters 

If the STATS FEP SUMMARY display shows that one type of terminal or device is doing too 
much output, the system manager can throttle the line(s) and/or terminal or device type. 
The system manager can also Increase the throughput for certain line(s) and/or terminal 
or device type(s). This throttling or unthrottiing is done by using the NETCON 
processor BLOCK and UNBLOCK porometers. 

The system manager con use the BLOCK and UNBLOCK options on the NETCON processor CONFIG 
command to throttle a particular line. The system manager con use the BLOCK and UNBLOCK 
options on the NETCON processor DEFAULT command to throttle a porticulor type of 
terminal or device. The system manager can use the BLOCK and UNBLOCK options on the 
NETCON processor SET command to throttle asynchronous terminals based upon their line 
speed. 

The system manager uses these BLOCK and UNBLOCK parameters to speed up or slow down the 
effective line speed of a terminal or device. The effective line speed needs to be 
changed only if necessary to meet the system goals and objectives. 



BUFSIZE NETCON Parameter 

The system manager con use the BUFSIZE option on the NETCON processor CONFIG and DEFAULT 
commands to change the default buffer size of an asynchronous line. This parameter 
needs to be specified for those tines on which an asynchronous device (e.g., a PC) is 
transmitting to the FEP at line speed. When a device transmits to the FEP at line 
speed, the default buffer size needs to be changed to equal the largest record sent from 
the device to the FEP. This prevents the FEP from losing input characters while trying 
to switch to o larger Input buffer. 
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INQSZ TIGR Parameter 



The system manager can control the number of pages of host memory that is to be used for 
the input circular queue for each local FEP. A minimum of two pages should be 
specified. If the local PEP has one or more remote FEPs connected to it or if the local 
PEP has several high-speed input devices in operation concurrently (e.g., HASP link, PC 
file transfer, etc.). more than two pages should be specified. 

The number of pages in the input circular queue is specified by the INQSZ option on each 
TIGR processor PEP command. If INQSZ is not specified, a value of one is used. The 
maximum value that may be specified is four. 



OUTZSZ TIGR Parameter 

The system manager con control the number of pages of host memory that is to be used for 
the output circular queue for each local PEP. A minimum of two pages should be 
specified. If the local PEP has one or more remote PEPs connected to it or if any PEP 
progroms ore used on the PEP or its RPEP(8), more than two pages should be specified. 

The number of pages in the output circular queue is specified by the OUTQSZ option on 
each TIGR processor PEP command. If OUTQSZ is not specified, o value of one Is used. 
The maximum value that may be specified is four. 



STATS STATISTICS Display 

The STATS processor STATISTICS command can be used to display the minimum, maximum, 
average, and standard deviation of all STATS items. The following is on example of the 
STATS STATISTICS display. 
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Figure 22. STATS STATISTICS Display 



The values shown in the STATISTICS command display are for the selected interval. While 
the GLOM command displays do their calculation using only the first and last STATS log 
record within the interval » the STATISTICS display is based upon calculations using 
every record within the interval. Therefore, the STATISTICS values are generally more 
accurate than the GLOM values. The STATISTICS values ore used as more detailed 
information for the various GLOM displays. 
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